Download a document
The transmitted XML, the Tax Data Document, or a rendered PDF — by the same transaction id.
/v1/api/transactions/{transaction_id}/invoice.xmlFour routes, all taking the same transaction_id from a transaction —
outbound or inbound, generated or raw:
| Path | Returns |
|---|---|
/invoice.xml | The UBL that actually crossed the network — the legal original |
/tdd.xml | The Tax Data Document filed for it |
/tdd | Alias for /tdd.xml. Same handler, same response — never out of sync with the other |
/invoice.pdf | A PDF rendered from invoice.xml, including the Fawtara QR code where one exists |
The kind is part of the path rather than a query parameter, so a downloaded file can be saved as-is without inspecting a content type first.
| Field | Type | Description | |
|---|---|---|---|
| taxpayer_id | uuid | optional | Query parameter, same convention as Get a transaction. Narrows the lookup to one taxpayer; omit to search every taxpayer your organisation manages |
Every response carries Cache-Control: no-store — a tax document should not be held by an
intermediary's cache — and a Content-Disposition naming the file after the invoice number, falling
back to the transaction id when there isn't one.
The PDF is rendered from the XML, not stored separately
There's no independently-stored PDF to drift from the document that actually transmitted. The QR code travels outside the UBL — Oman keeps it out of the schema entirely — so a received document's PDF renders without one: the sender's QR was never in their XML for SUMU to read back.
A 404 distinguishes three cases by message: no such transaction at all, a draft with no XML yet
(invoice.xml/invoice.pdf before the document is finalised), or no tax report filed yet
(tdd.xml/tdd before one exists).