List transactions
One paginated feed spanning everything a taxpayer sent or received, drafts included.
/v1/api/transactionsOne feed for everything a taxpayer sent or received: invoices generated through
Create invoice, raw UBL sent through Send raw UBL,
and documents that arrived from another participant — merged and ordered by updated_at. Left
unfiltered, it also includes drafts (save_as_draft invoices that were never issued). Each entry is a
summary; call Get a transaction for the same row with full
delivery/tax_report/events detail, or Download a document for the
transmitted XML or a rendered PDF.
direction and source tell you which side of the feed a row came from: outbound is something the
taxpayer sent (by either pipeline), inbound is something that arrived for them; generated only
applies to an invoice built from JSON, raw covers a raw UBL send and anything received. events is
only ever populated on the single-transaction read — listing many rows does not fetch history for each.
| Field | Type | Description | |
|---|---|---|---|
| taxpayer_id | uuid | optional | Narrow to one taxpayer. Omit to span every taxpayer your organisation manages |
| direction | enum | optional | inbound or outbound. Omit for both |
| status | enum | optional | One of queued · sent · delivered · failed · skipped · received · draft — see Status values |
| tax_report_status | enum | optional | One of pending · submitted · acknowledged · rejected — find everything the Authority hasn't yet acknowledged |
| updated_since | datetime | optional | ISO 8601 with offset. Only transactions that changed since this timestamp — built for a polling connector's resume point, not a created-at range filter |
| order | enum | optional | asc (default) or desc, by updated_at. Anything else is a 400 |
| limit | integer | optional | 1–100, default 10 |
| offset | integer | optional | Default 0 |
status and direction can disagree
received and draft each imply a direction on their own — received means inbound, draft only
ever exists outbound. Naming a status and a contradicting direction in the same request (e.g.
direction=outbound&status=received) matches nothing rather than silently dropping half the filter;
you get an empty page back, not an error.