List recent orders

GET/api/v1/orders
Required scope:orders:read

See your most recent orders, up to 100, newest first. This is not your full order history and it should not stand in for a database on your side: it has no filters, no paging, and anything older than the last 100 orders cannot be reached through it again. The right pattern is to store every order_id on your side when you place the order, then read them one at a time with GET /api/v1/orders/{order_id} when you reconcile. Use this list to eyeball what happened recently, or to hunt down an order whose order_id you genuinely lost.

Do not use this list as your order database

This endpoint returns at most the 100 most recent orders, with no cursor and no filters at all — you cannot page, and anything older than that cannot be reached through it again · Every call makes us read your account's entire order history first and only then trim it to 100, so the cost of one call grows on its own every day as your orders accumulate · Polling this list in a loop to track order state is therefore the slowest and most expensive way to do something that belongs on your side anyway · Record every order_id when you place the order, then track state with GET /api/v1/orders/{order_id} one order at a time. Keep this list for eyeballing recent activity, or for hunting down an order whose order_id you genuinely lost.

The authentication refusals reach this endpoint too

The five refusals at the authentication gate — invalid_key (401) · key_revoked (401) · insufficient_scope (403) · quota_exceeded (429) · too_many_inflight (429) — can happen on every endpoint, this one included, because they are thrown before the request reaches a single line of this endpoint's own logic (the scope it needs is the one declared at the top of this page). The response tabs above therefore list only what this endpoint itself answers; that is not a claim that those five cannot happen here. All of the detail lives in one place, on the identity endpoint page at /developers/access/me: the HTTP status of each one, which of them spend your daily quota, which headers come back, and why the two 429s need opposite handling. It is deliberately not copied onto every page, because the second copy is the one nobody remembers to update the day the rules change.

Request parameters

Header

NameTypeHow to use it
AuthorizationRequiredstring
Your key as Bearer <key>
Details and caveats
  • required on every request
  • The list only ever contains orders belonging to the account this key is attached to; another reseller's orders can never appear in it.

Response fields

NameTypeHow to use it
ordersarray of objects
Orders, newest first
Details and caveats
  • Each entry is identical field for field to what GET /api/v1/orders/{order_id} returns for that same order: order_id
  • status
  • type
  • product_id
  • price
  • charged
  • delivery
  • error
  • created_at
  • updated_at
  • The same two rules apply here as there
  • delivery comes in two shapes decided by the type on that same order, and how much an order was charged is answered in one place only, charged
  • Each field is described one by one on the single-order page (/developers/orders/get)
  • No field tells you how many older orders exist, because this endpoint was never meant for walking the whole history.

Possible statuses

StatusCodeMeaning
200—
Orders exist — the most recent ones come back
Newest first · The example mixes an order still waiting in the queue, one that was delivered and one that closed as failed, which is perfectly normal.
200—
No orders yet — an empty array, not a 404
An account that has never ordered anything gets this · orders is an empty array, not null and not a 404, so your code can iterate it without checking first.
Last updated 2026-09-07