Skip to main content
Everything in the API follows the same handful of rules. Read this once and the rest of the reference reads itself. Base URL: https://api.orqex.com/v1

Response envelopes

A write returns a message and the resource:
A read returns the resource alone:
A list returns an array and a pagination block:

Amounts

Every amount in a response is an object, so you never have to format it yourself:
Amounts in a request are plain numbers in major units, on every resource — payment intents, checkout sessions, refunds and payouts alike. 50 means 50.00, never 0.50. The minimum is 1. An amount is stored and charged at the scale its currency supports. Currencies with two decimals keep them: 145.67 stays 145.67. Currencies that have no minor unit cannot hold a fraction, so 6741.26 is recorded and collected as 6742 — the response returns the amount that will actually be charged, which is the one to reconcile against.

Exchange rates

When a response includes a currency conversion, exchange_rate is an object:
value is the number of destination-currency units for one source-currency unit. Use from_currency and to_currency instead of inferring the direction from nearby amounts. expression is display-ready; use value for calculations.

Pagination

Lists are cursor-paginated. Pass per_page to size the page, and follow next_cursor or next_page_url to walk forward.
Stop when has_more_pages is false. Cursors are opaque — do not parse or construct them.

Idempotency

Send X-Idempotency-Key on any POST to make a retry safe. The key is a string you choose, 8 to 128 characters, unique per logical operation.
The first response is stored for 24 hours. Repeating the request with the same key replays that stored response — same status, same body — and adds X-Idempotent-Replayed: true. No second payment is created. Use it wherever a network timeout would otherwise leave you unsure whether the call landed: creating intents, attempts, refunds and payouts. Safe methods (GET) ignore the header.

Rate limits

Limits depend on the operation. Transaction creation has a high safety ceiling, ordinary reads have their own per-key budget, and live status operations are additionally limited per transaction. See Rate limits for the complete table and polling guidance.

Timestamps and identifiers

Timestamps are ISO 8601. Identifiers are opaque strings with a resource prefix (pi_ for a payment intent, rq_ for a requery, and so on). Treat them as strings; do not infer meaning from their contents beyond the prefix.