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.

executionSource
enum<string>

The execution source to keep: RFQ (RFQ block fills) or CLOB (order-book fills), the values of each trade's executionSource. Omit for every fill. RFQ covers recent fills (the hot trade store); older RFQ fills stay on the unfiltered pages

Available options:
RFQ,
CLOB
Minimum string length: 1

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.

The walk covers the pair's whole history: recent and archived trades are read together, in one statement, so the empty token is the end of the pair's history, not of a retention window.