Skip to main content
GET
Recent Trades

Path Parameters

tradingPairId
string
default:893d2add-2f36-4ee7-b660-893d2add2f36
required

Query Parameters

pageSize
integer<uint32>
default:25

Max trades to return (max 1000)

Required range: 1 <= x <= 1000
pageToken
string

Pagination cursor with two states:

  • Omitted or empty string (""): start a cursor walk with no prior position, from the most recent trade (this listing always sorts newest-first).
  • Non-empty: an opaque cursor from a previous response's next_page_token; results resume immediately after that position.

The walk is a keyset seek on (executed_at, id), both immutable once a trade is written, so a page can neither repeat nor skip a trade when new fills land mid-walk — the failure the removed page number had by construction on a table this endpoint appends to continuously. trading_pair_id is pinned inside the token, so a token minted for one pair is rejected rather than seeking into another pair's history.

Response

OK

Recent trades for a trading pair.

trades
object[] | null
pageSize
integer<uint32> | null

Maximum number of trades returned

Example:

25

nextPageToken
string | null

Cursor for the next page, under proven semantics: the read over-fetches one row past page_size, so an empty token means the walk is finished and a non-empty token means a further trade was actually seen. Unlike ListUserTradesResponse.next_page_token (AIP-158 "maybe more"), a client can stop here on the empty token without a confirming extra request — this listing reads one table, so there is no hot/archive interleave that could hide rows behind a short page.

That one table is the hot trades table, so a walk reaches the end of the archiver's retention window rather than the end of the pair's history. This is the endpoint's long-standing scope, unchanged by the cursor.

There is no public walk over a pair's ARCHIVED history, and this endpoint is not a partial one — do not point market-data consumers at the user trade listings to continue it. GetUserTrades / ListUserTrades do merge the archive, but they are authenticated and user-scoped (auth.user_id is the read's first mandatory filter), so they return only trades where the caller was maker or taker. Following them to extend a public pair tape would silently drop every fill between two other parties. An individual archived trade does stay publicly reachable by id: GetTradeById falls back to the archive table on a hot miss.