/developer/transactions. Every request needs Authorization: Bearer <access_token> and X-On-Behalf-Of: <company_id> — see Authentication.
Endpoints
List transactions
transaction_at descending unless you pass sort and order.
What the list includes by default
- Every status, including
pendinganddeclined, so in-flight payments are visible. - Only accounts the API key’s member can access. Members without account scopes see an empty list.
- Excluded unless you filter for them explicitly with
type: the reward typesloyalty_out,points_in,points_out, andtrophy. - Excluded unless
scheduled=true: payments scheduled for a future date. - Looking rows up by
idsorsource_payment_idsbypasses both exclusions.
Filters
All list filters accept comma-separated values where noted.
Invalid values return 400 with
{ "error": "<message>" }.
Pagination
Use cursor pagination for syncs and exports. Each page oflimit rows (default 50, max 200) includes next_cursor when more rows exist. Pass it back as cursor with the same filters:
sort or order mid-walk. next_cursor is absent on the last page.
Offset pagination (offset) is available for UI-style paging and adds a total count to the response. cursor and offset cannot be combined.
Enrichment
Adduser=true to include the initiating user’s name and avatar, and card=true to include the card’s name, last four digits, and type on card transactions. Recognised merchants always include enriched_merchant with a display name, category, and icon.
Get a transaction
Amounts and signs
Every amount is a{ "value": "<decimal string>", "currency": "<ISO 4217>" } object. Values are signed: debit transactions are negative and credit transactions positive. Parse value as a decimal, never as a float.
Status lifecycle
pending moves to exactly one of completed, declined, or reversed, all of which are terminal. Card authorisations start pending and become completed on settlement. A completed transaction that is later refunded appears as a separate refund transaction rather than changing status.
Subscribe to transaction.create and transaction.update webhooks to be notified of these changes instead of polling.
Transaction types
direction is set per transaction by the originating system, so always read it from the transaction rather than inferring it from type.