A double-entry bookkeeping API that accepts crypto micropayments

Two things at once — and why that pairing is rare

"A double-entry bookkeeping API that accepts crypto micropayments" is really two requirements stacked together, and most tools give you only one:

• Double-entry bookkeeping over an API — balanced, immutable, auditable books you reach over HTTP, not a spreadsheet or a desktop app.
• Crypto micropayments as the payment rail — you settle the bill in stablecoin per call, at sub-cent amounts, without an account or a subscription.

Traditional bookkeeping APIs (QuickBooks, Xero, or a raw Postgres ledger you host) bill by monthly seat and human signup. Crypto payment rails (x402 facilitators, payout APIs) move money but don't keep books. Ledger is built for the intersection: correct double-entry accounting whose access is itself metered in USDC micropayments — the shape an autonomous agent actually needs, because an agent can neither fill in a billing form nor safely track money in a single mutable variable.

How the crypto-micropayment side works

Every paid endpoint speaks x402. Call it without payment and you get a machine-readable 402 quoting the exact price; sign a USDC transfer for that amount and retry. There is no invoice, no card, and no minimum — the payment is a single-use signed transfer settled by an x402 facilitator, and the API never custodies funds.

# Ask the ledger for a trial balance without paying
GET /ledger/reports/trial-balance

HTTP/1.1 402 Payment Required
{"x402Version":1,"accepts":[{
  "scheme":"exact","network":"base",
  "maxAmountRequired":"2000",              # $0.002, in USDC 6-decimal units
  "asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "payTo":"0xBEccE6dd106Cfa910F78fea188B2fcCEb73bdD0F"}]}

# Sign a USDC transfer for that amount and retry
GET /ledger/reports/trial-balance
X-PAYMENT: <base64 signed USDC payment payload>

HTTP/1.1 200 OK
{"debits":15000,"credits":15000,"balanced":true}

Amounts are USDC minor units (6 decimals), so 2000 = $0.002 for a read and a write is 10000 = $0.01. If your agent has standing access you can skip x402 with a capability token instead — see capability tokens vs x402.

How the double-entry side works

The books themselves are real double-entry: every transaction is a set of entries that must sum to zero, enforced by database triggers (not just application code), and entries are immutable — you reverse, never delete. Recording a $0.002 x402 spend against your own books is one balanced transaction:

POST /ledger/transactions
{"date":"2026-07-01","description":"x402 read: trial-balance",
 "entries":[
   {"account_id":5,"amount":2},     # Expense: API costs   +$0.002
   {"account_id":1,"amount":-2}     # Asset: USDC wallet    -$0.002
 ]}

# 201 Created
{"id":42,"balanced":true,"entries":2}

The invariant means the books can't silently drift, and every balance is derived from recorded events rather than stored and risked. For the full model — the five account types and the sum-to-zero rule — see double-entry accounting for AI agents.

Put it together in five HTTP calls

1. Create a USDC-wallet asset account and an API-costs expense account (POST /ledger/accounts).
2. Call a paid endpoint, get the 402, and pay $0.002 in USDC on Base to read your trial balance.
3. Record that spend as a balanced transaction (POST /ledger/transactions, entries sum to zero).
4. Read the trial balance again to confirm debits equal credits (GET /ledger/reports/trial-balance).
5. Made a mistake? Reverse it, don't delete it (POST /ledger/transactions/{id}/reverse).

The quickstart shows each call end to end against the live API.

What it costs and what it doesn't require

If you're evaluating build-vs-buy, the buy-vs-build guide is the honest version: build it yourself if accounting is your core product, rent it if you just need correct books an agent pays for.