binance_get_convert_history
Retrieve past Binance conversions for any date range, automatically walking 30-day windows to cover older periods and locate order IDs.
Instructions
List past conversions, either for one <=30-day window or across a walked range.
Calls GET /sapi/v1/convert/tradeFlow (SIGNED, UID weight 3000 per call of a
180,000/min budget — 60 calls a minute at most, and the default budget here spends
72,000 of it).
Binance requires both startTime and endTime and caps the span at 30 days, and
the endpoint has no cursor/offset/page parameter of any kind. The only
continuation it offers is the moreData flag: when it is true, the same window is
re-asked with endTime = min(createTime) (inclusive — an exclusive - 1 would drop
rows tied on that instant but cut off by limit; the re-read duplicates are deduped by
orderId) until it comes back false. Both modes below automate that.
Single window (default):
start_time/end_time. Give one and the other is filled locally by the 30-day rule; give neither and the last 30 days are used.Walk:
since(plus optionaluntil/resume_before) slices the range into <=29-day windows, newest-first, untilsinceis reached ormax_callsruns out.
The two sets are mutually exclusive — mixing them is rejected locally.
When to Use:
To reconcile conversions for a period, or to find the orderId of a past conversion.
To pull more than 30 days of history without hand-rolling the windowing (walk mode).
When NOT to Use:
To check one conversion you just made —
binance_get_convert_order_statusis UID 100 against this endpoint's 3000.For resting limit orders, which are not conversions yet —
binance_get_convert_open_limit_orders.
Returns:
Conversions newest-first (time, from → to amounts, ratio, status, orderId), deduped by
orderId within the call, the number of API calls spent, and — when the walk stopped
early — a resume_before cursor marking the boundary of the next unfetched range.
A failure mid-walk returns the rows collected so far plus that cursor and the
error, never the error alone. Markdown display caps at 50 rows;
response_format="json" carries every fetched row.
Pagination/Windows:
start_time/end_time/since/until/resume_before all accept epoch ms, a
=12-digit epoch-ms string, or ISO-8601. A single-window span over 30 days is rejected here with a clear message rather than sent on to become a Binance error.
limitis <= 1000 (the endpoint's own max).resume_beforeis always theendTimethe next request would have used, so resuming never leaves a gap; overlapping rows are deduped.
Examples: params = {} # the last 30 days, one window params = {"start_time": "2026-08-01", "end_time": "2026-08-20"} params = {"since": "2026-01-01", "max_calls": 12} params = {"since": "2026-01-01", "resume_before": 1756000000000}
Error Handling:
-1127 means the span exceeded Binance's cap (this tool validates first, so it should
not appear); 429 on /sapi means the UID weight budget is gone — lower max_calls and
wait; -2015 means the key lacks permission or the IP is not allowlisted.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |