Order-X does for purchase orders what Factur-X did for invoices: one PDF/A-3 that procurement software parses and purchasing managers read. Post order JSON and get back a branded PDF with the Cross-Industry Order XML embedded, validated against the official Order-X 1.0 rules before it reaches you. Orders, order changes, and order responses, all from the same endpoint.
curl -X POST https://api.invoicexml.com/v1/create/order-x \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "order": { ... }, "options": { "typeCode": "220" } }'
Content-Type: application/pdf X-Invoice-Valid: true // order.pdf · XMP fx:DocumentType ORDER // embedded: order-x.xml (Cross-Industry Order) // guideline: urn:order-x.eu:1p0:comfort
Like Factur-X, Order-X scales its data requirements through conformance profiles. Pick one with options.profile on creation, or send nothing and get COMFORT. On validation the document's own guideline identifier decides which rule set runs; unknown identifiers fall back to COMFORT with a warning instead of a hard fail.
| Profile | Slug | Guideline identifier | What we run |
|---|---|---|---|
| BASIC | basic | urn:order-x.eu:1p0:basic | Order-X 1.0 XSD plus the BASIC Schematron: the core order data |
| COMFORTDefault | comfort | urn:order-x.eu:1p0:comfort | The full exchange profile most trading partners agree on |
| EXTENDED | extended | urn:order-x.eu:1p0:extended | Everything in the standard, for complex supply-chain scenarios |
An order is rarely the last word. Order-X models the exchange as three UNTDID 1001 document types, and options.typeCode picks which one you are issuing. Same request body, same endpoints.
Create the hybrid PDF or just the XML; validate either and get a verdict, or a printable report. One API key, the official Order-X 1.0 artifacts behind every call.
Order JSON in, branded PDF/A-3 out, with the CIO XML embedded and the profile stamped. Optional language, brand colour, logo, or your own PDF.
Read the referenceThe same request, returning only the Cross-Industry Order XML for systems that embed or transmit it themselves.
Read the referenceDrop a hybrid PDF or raw CIO XML. The profile is read from the document, and findings name the rule that objected.
Read the referenceThe same verdict as a printable report, with the outcome also in the X-Invoice-Valid response header.
Read the referenceEvery Order-X document runs the official XSD first, then the Schematron for its declared profile. The answer is always a structured verdict your pipeline can branch on, whether the input was a polished hybrid PDF or something a supplier exported wrong.
{
"valid": false,
"errors": [
{
"rule": "PDF-EMBED",
"message": "No embedded order-x.xml was found
in this PDF. Order-X documents carry the
Cross-Industry Order XML as a PDF/A-3
attachment; this file has none."
}
]
}
Your invoices are processed in memory and returned in the same response. Zero data retention is not a policy we enforce, it is an architecture we built.
Processed in volatile memory only. Never written to disk, never queued, never backed up.
Servers in Frankfurt, Germany. No transfers outside the European Economic Area.
Never used for analytics, never to train AI models, never shared with third parties.
SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.
GDPR compliant by design · nothing stored on our servers
Order-X is the purchase-order sibling of Factur-X and ZUGFeRD, published jointly by FNFE-MPE and FeRD. It carries a UN/CEFACT Cross-Industry Order (CIO) XML inside an ordinary PDF/A-3, so the same document works for purchasing software and for the humans who approve orders.
Same authors, same hybrid model, different business document. Factur-X embeds an invoice, Order-X embeds an order. If your billing already runs on Factur-X or ZUGFeRD, Order-X closes the loop on the ordering side with the identical PDF/A-3 technique.
All three: BASIC, COMFORT, and EXTENDED, selected with options.profile on creation. COMFORT is the default when you send nothing. On validation the profile is read from the document's own guideline identifier, and each profile runs the official Order-X 1.0 XSD plus its own Schematron rules.
Yes. options.typeCode selects the UNTDID 1001 document type: 220 for an order (the default), 230 for an order change, and 231 for an order response. The same endpoints and the same request body cover all three.
Yes. POST /v1/validate/order-x accepts either a hybrid PDF, from which the embedded order-x.xml is extracted, or a plain Cross-Industry Order XML file. A PDF with no embedded order XML comes back as a normal verdict with valid: false and the rule PDF-EMBED, so your pipeline handles it like any other finding.
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.