binance_get_pay_history
Walk up to 18 months of Binance Pay history without hitting 90-day or 100-row limits. Get deduplicated transactions newest-first and a resume cursor for large or interrupted pulls.
Instructions
Walk up to 18 months of Binance Pay history, past the 90-day / 100-row API caps.
Repeatedly calls GET /sapi/v1/pay/transactions (UID weight 3000 per call) in
<=89-day windows, newest-first, from since (default: Binance's 18-month lookback
plus a two-day margin; an older since is clamped to it) up to now, or up to a resume_before cursor
from a previous truncated call. A window that comes back with exactly 100 rows (the
page limit) is bisected — split at its midpoint and re-walked — so a dense period is
not silently dropped; if bisection reaches its 1 ms floor and STILL gets a full page,
those extra rows are dropped and the response says so (possibly_incomplete).
Spends at most max_calls requests (default 30 = 90,000 UID) before stopping; the
returned resume_before cursor always marks the boundary of the next unfetched
range (never derived from which rows happened to come back), and is omitted
(no_progress) on the rare case the budget ran out before even the newest window
could make any progress — resuming then would just repeat the same calls, so raise
max_calls instead.
Binance Card spending is NOT available via API; card-funded Pay payments appear here
with walletType 4 or 6 ("card").
When to Use:
To pull a full Pay history for reconciliation without hand-rolling the 90-day windowing or the 100-row-per-window cap.
To resume a previous run that stopped early — pass the same
sinceplus itsresume_beforeback in.
When NOT to Use:
For a single recent window —
binance_get_pay_transactionsis one call and cheaper.
Returns:
Markdown (or JSON) list of transactions deduped by transactionId (scoped to this one
call — not a persistent cross-call dedupe) sorted newest-first, the number of API
calls spent, and — when the budget ran out before reaching since — a resume_before
cursor to pass back on the next call alongside the same since. Markdown display is
capped at 50 rows; response_format="json" always carries the full set collected by
this call (only clip_response's byte cap applies).
Pagination/Windows:
since accepts an ms epoch, a >=12-digit epoch-ms string, or an ISO-8601 string,
default now minus 18 months (+2 days); anything older is clamped to that floor and
reported as since_clamped. Each top-level window is at most 89 days (under
Binance's 90-day cap); a window may cost more than one call if it has to be
bisected, so max_calls bounds total calls, not windows. resume_before is always
the boundary of the next unfetched range, so a resumed call never re-walks
already-collected ranges (aside from harmless dedupe-caught edge overlaps).
Examples: params = {} # last 18 months, up to 30 calls params = {"since": "2026-01-01", "resume_before": 1700000000000, "max_calls": 10}
Error Handling:
A request failure mid-walk does NOT discard what was already fetched: the rows
collected so far come back with resume_before (the boundary of the next unfetched
range) and the failure itself in stop_error — fix the cause, then call again with
the same since and that resume_before. no_progress: true with no cursor means
nothing was collected before the failure — clear the cause and repeat the same call.
A range that ends before Binance's 18-month lookback is refused locally (nothing in
it is retrievable). -2015 means the key lacks permission or the IP is not on the
key's allowlist.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |