Skip to main content
Each entry represents a single debit or credit line against one of your sub-accounts, with a balance before and after. When the movement was generated by a Noxpay process — Crossramp Checkout, onramp, offramp, withdrawal — the full transaction object is embedded inline.

Query parameters

Both bounds are inclusive and filter on the journal entry date, not on the originating transaction’s creation date.
A bare YYYY-MM-DD in date_to resolves to midnight at the start of that day, so date_to=2026-08-20 excludes everything that happened during 20 August. To include a whole day, pass the next day, or use an explicit RFC 3339 timestamp.
An unparseable date is discarded and the filter simply does not apply — you get an unfiltered result rather than a 400. An unrecognised account_type behaves the same way: the whole statement is returned. Validate these client-side if it matters. An invalid limit falls back to 50 rather than returning an error.

Response fields

Statement entry

Account sub-type from code

The last segment of account.code identifies the sub-account bucket:

Embedded transaction object

When transaction is present it is the standard Transaction Object, minus version. It carries no resource-type field, so identify the product from which attribute keys are present — these are the kinds of process that can appear: The attributes object contains the fields relevant to that product. See the per-resource pages for full attribute tables.

Status codes