Get balance history
Why the balance is what it is.
Path parameters
orgIdstringRequiredThe opaque organization id issued to you, normally CUID-shaped (for example
cmsx…). It is not anorg_-prefixed alias. Pass it unchanged in every organization-scoped path.
Query parameters
limitintegerOptionalDefaults to100Maximum entries to return, from 1 to 500. Defaults to 100. Out-of-range values are clamped, not refused.
cursorstringOptionalThe
nextCursorfrom your last page: entries after that one. Entries are append-only, so carrying it gives you what settled since — including a reversal appended days after the debit it reverses. A settlement recorded after its own settlement time is the exception (see above);GET /balance_transactionshas none. Opaque; do not build one. Sendcursororsince, not both.sincestring<date-time>OptionalDeprecated: use
cursor. Entries strictly after this time. Two entries can share a millisecond, and paging on the last one's time skips the rest of that millisecond;cursorcannot.
Behavior
Every movement, in the order it settled, with the running balance after
each. balanceAfter is published only when the running total reconciles
with GET /balance; otherwise a note says so and the entries stand
alone.
Entries are ordered by settlement time: a deposit by when it completed,
not when it was first seen. A settlement we record late (a deposit whose
completion reaches us after its own settlement time) is dated when it
settled, so it can land behind a cursor you already hold and not be
re-delivered. This view is for reading the balance's story. For exact
incremental reconciliation, page GET /balance_transactions, whose id
is assigned when a row is written and never lands behind one you have
seen.
Limited to 60 requests per minute per credential, below the read budget,
because each call replays your whole history. A high-frequency poller
belongs on GET /balance_transactions.
What adds an entry: a deposit to your funding account once it has
completed (never while pending), a sandbox top-up, and a payout drawn
from the prefunded balance (DEBITED). A debited payout that fails or is
canceled with the money coming back keeps its original debit and gains a
separate reversal entry (RETURNED or CANCELED); there is no
zero-delta row. One rejected by compliance stays debited.
What adds nothing: a payout you fund from your own wallet (one that
returns funding instructions, or requiresFunding in sandbox) never
touched the balance, including when you cancel it before funding. Nor
do movements on a payment network whose balance this record does not
track. When those leave the running total short of GET /balance,
balanceAfter is withheld under a note.
The whole history is read on every call, so hasMore is exact. An
organization with more than 100,000 orders is more than this view can
replay and gets 413 HISTORY_TOO_LARGE; page GET /balance_transactions
instead, which has no such ceiling.
Responses
200Movements, in settlement order.
Body
hasMorebooleanOptionalnextCursorstring | nullOptionalFeed back as
cursor. It is NOT null when you are caught up: an empty page returns the position you sent — terminate onhasMore: false. Null only when the history is empty and nocursororsincewas sent.nextSincestring<date-time> | nullOptionalDeprecated: use
nextCursor. The last entry's time; paging on it skips entries sharing that millisecond. Feed it back assince. It is not null when you are caught up: an empty page returns thesinceyou sent, so terminate onhasMore: false. A loop waiting for null never ends. Null only when the history is empty and nosincewas sent.entriesarray of objectOptionalShow 8 properties
idstringOptionalThe payout or deposit id; a reversal is
<payoutId>:reversal.typestringOptionalreversalis a debited payout's money coming back, returned by the bank (RETURNED) or canceled (CANCELED): a separate appended entry, never a rewrite of the original debit.Allowed values:fundingpayoutreversalstatusstringOptionalWhat this entry records, frozen when it was written, and not the payout's current status, which would make a historical row mutate under a reconciler that had already read it.
DEBITEDmoney left,RETURNEDmoney came back from a failed payout,CANCELEDmoney came back from a canceled one,COMPLETEDfunding landed.Allowed values:COMPLETEDDEBITEDRETURNEDCANCELEDcurrencystringOptionalamountstringOptionalbalanceAfterstringOptionalPresent only when the ledger reconciles with
GET /balance.referencestringOptionalYour payout
reference. Absent when there was none (a sandbox top-up has none).atstring<date-time>Optional
Errors
400VALIDATION_ERROR—cursorandsincesent together, a cursor that is not one we issued, or a malformedsince.401The key was refused. Nothing ran.
UNAUTHORIZED: missing, invalid or revoked, or a key on a route that does not accept one.KEY_EXPIRED: the key passed the expiry it was issued with. Issue a new one; an expired key cannot be rotated.KEY_IP_NOT_ALLOWED: the key is pinned to source addresses and this request came from another.
403A valid key that may not make this call. Nothing ran.
FORBIDDEN: the key belongs to a different organization.ACCOUNT_BLOCKED: API access for your organization is suspended, and every key is refused until we lift it. Contact support.
413HISTORY_TOO_LARGE— this organization has more orders than this view replays. PageGET /balance_transactions.429Too many requests. The default ceiling is 100 requests per minute per API credential on a 60-second window. High-volume payout and reconciliation routes declare a 600/minute override, and batch submission a 30/minute ceiling. A separate 2,000/minute per-source-IP abuse ceiling always applies.
Obey
Retry-After; it is in seconds and is authoritative. A 429 means the request was refused before the handler ran. Retry reads normally; retry an idempotent mutation with its sameIdempotency-Key.
Error body · Error
typestringRequiredStable machine-readable code.
detailstringRequiredWhat went wrong, in a sentence. Always a string, so
detail.toLowerCase()is safe.More
This is the field to read on
BAD_REQUESTandPROVIDER_REJECTED, where the type alone does not name the condition.messagestringRequiredThe same text as
detail, kept for integrations written beforedetailexisted. Readdetail.resolutionstringOptionalWhat to do about it, when there is a specific answer. It is not on every error (it is absent on
BAD_REQUEST,NOT_FOUND,PAYOUT_NOT_CANCELABLEandDESTINATION_ACCOUNT_NOT_FOUND), so treat it as optional and fall back todetail.statusintegerRequiredHTTP status, repeated in the body.
statusCodeintegerRequiredThe same value as
status, kept for integrations written beforestatusexisted. Readstatus.requestIdstringRequiredQuote this to support and we can find the exact request. Also sent as the
x-request-idresponse header, which is the only place it appears on a successful response. Success bodies do not carry it. Send your ownx-request-idon the request and we use it, so your trace and ours share one identifier; otherwise we mint one.errorsarray of stringOptionalPresent on VALIDATION_ERROR; names each field that failed.
originalIdempotencyKeystringOptionalOn
DUPLICATE_REQUEST_DETECTEDonly. Send the request again with this to receive the original payout instead of making a second one. Without it there is no way to recover except by risking a double payment.originalPayoutIdstringOptionalOn
DUPLICATE_REQUEST_DETECTEDonly. The payout the first request created.originalBatchIdstringOptionalOn a batch
DUPLICATE_REQUEST_DETECTED. The run the first request created.originalRequestIdstringOptionalOn a
409 PAYOUT_OUTCOME_UNKNOWNreplay. TherequestIdof the call whose outcome is unknown; quote it to support.existingRecipientIdstringOptionalOn
BANK_ACCOUNT_ALREADY_LINKED. The recipient in your organization that already holds this account.existingMethodIdstringOptionalOn
BANK_ACCOUNT_ALREADY_LINKED. The payment method on that recipient.
Branch on type, never on the status or the message. Every error type is listed with what to do about it.
Was this page helpful?