Skip to main content
Status: the dedicated statement endpoints described below (CSV, JSON) are coming. In the interim, settled-order details are retrievable per-intent via GET /api/v1/orders/{intent_id} (full settled record). Scheduled batch statements are on the roadmap.
Statements is the default integration path for the accounting side of the workflow. Your GL ingests settlement confirmations on a daily or weekly cadence; your treasury archive takes a monthly record set. For institutions wiring real-time accounting or TMS-driven reconciliation, see Programmatic Access.

​
Statement types

One row per settled intent, over a date range. Columns match the general ledger handoff:Status: coming. Interim: the per-intent endpoint returns the same data one order at a time.

​
Filtering

Planned filters across all statement types:
  • Date range — from / to on settled_at
  • Status — SETTLED by default; include FAILED / EXPIRED for operational reviews
  • Counterparty — limit to a specific receiver institution
  • Currency pair — limit to JPYSC0 → USDCx, etc.

​
Consuming statements

Once statements land, your accounting systems ingest them via your existing pipelines — whatever you use today to ingest daily settlement files from banks or other counterparties. Most institutions schedule a daily CSV pull into their GL and a monthly JSON dump into their treasury archive.

​
Interim: per-intent retrieval

Until batch endpoints ship, settled-order details are retrievable one at a time:
Returns the full settled FXOrder record — structurally the same content that will appear in batch statements, just retrieved on demand. If your accounting team needs records now, scripting against this endpoint is the path; when batch endpoints ship, switch the scheduled job from a per-intent loop to a single batch call.

​
Next steps