UAE e-invoice preflight API

New integrations have two canonical validation paths: XML at POST /v2/validateand canonical JSON at POST /v1/preflight. Existing clients can continue using POST /v1/validate as a legacy JSON/XML compatibility endpoint; usage and health are also available.

Current validation scope

POST /v2/validate accepts raw UBL 2.1 / PINT AE XML and runs format, structure (UBL 2.1 XSD) and semantic (rules + Schematron) layers. POST /v1/preflight accepts canonical JSON invoice data only. Existing POST /v1/validate clients retain the legacy JSON/XML compatibility behavior.

Authentication

Every call except GET /health requires a key. Send it as x-api-key or Authorization: Bearer <key>. Rate limits are per key; exceeding them returns 429.

x-api-key: <your-api-key>

Base URL: https://api.einvoicecheck.ae

POST /v2/validate (new XML integrations)

Send raw UBL 2.1 / PINT AE XML with Content-Type: application/xml or text/xml. This is the preferred canonical XML path and returns layered format, structure and semantic findings.

POST https://api.einvoicecheck.ae/v2/validate
x-api-key: <your-api-key>
content-type: application/xml

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <!-- UBL 2.1 / PINT AE Invoice or CreditNote -->
</Invoice>

200 response

{
  "valid": true,
  "inputFormat": "xml",
  "validationScope": "pint-ae-ubl-xml",
  "invoiceType": "380",
  "schemaVersion": "urn:peppol:pint:billing-1@ae-1",
  "format": { "status": "passed", "issues": [] },
  "structure": { "status": "passed", "issues": [] },
  "semantic": { "status": "passed", "issues": [] }
}

A malformed document fails the format layer and skips deeper layers. Structure and semantic findings remain independently visible when a document is structurally invalid.

Status	Meaning
200	The document was processed. Read `valid` and each layer status.
400	The request body is not raw XML. Canonical JSON goes to `/v1/preflight`.
401	Missing or invalid API key.
413	Document exceeds the accepted payload size.
429	Per-key rate limit exceeded.

POST /v1/preflight (new JSON integrations)

Send a bare canonical JSON invoice object. This is the preferred canonical JSON path; XML bodies and the legacy document/invoice wrappers are rejected.

POST https://api.einvoicecheck.ae/v1/preflight
x-api-key: <your-api-key>
content-type: application/json

{
  "invoiceType": "388",
  "invoiceNumber": "INV-2026-0001",
  "issueDate": "2026-07-26",
  "currency": "AED",
  "supplier": { "name": "Acme FZ-LLC", "trn": "100123456700003" },
  "customer": { "name": "Buyer LLC", "trn": "100987654300003" },
  "lines": [{
    "id": "1", "quantity": 2, "unitPrice": 500,
    "lineExtensionAmount": 1000,
    "taxCategory": { "code": "S", "rate": 5 }, "itemName": "Consulting"
  }],
  "totals": {
    "lineExtensionAmount": 1000, "taxExclusiveAmount": 1000,
    "taxAmount": 50, "taxInclusiveAmount": 1050, "payableAmount": 1050
  }
}

The response includes the flat errors shape plus validationScope: "canonical-json-data-preflight". This endpoint validates invoice data; validate final UBL XML through POST /v2/validate.

POST /v1/validate (legacy compatibility)

Existing clients remain supported. This route preserves canonical JSON, the { "invoice": { ... } } wrapper, the { "document": "<Invoice>..." } XML envelope, and raw XML, returning the legacy flat errors[] shape. It is not the recommended path for new integrations; there is no retirement date.

GET /usage

Returns per-key usage totals, outcome counts and recent calls. Submitted invoice payloads are not included in usage records.

GET https://api.einvoicecheck.ae/usage
x-api-key: <your-api-key>

GET /health

Unauthenticated liveness and readiness probe. Returns 503 when a required dependency is unavailable.

GET https://api.einvoicecheck.ae/health

API questions

What does the UAE e-invoicing API return?

POST /v2/validate returns a layered JSON result with format, structure and semantic statuses. POST /v1/preflight returns canonical JSON data findings. POST /v1/validate retains its legacy flat errors[] response for existing clients.

How do I authenticate?

Send your key in the x-api-key header or as a bearer token in the Authorization header. A key is issued when you create an account.

What validation layers are currently included?

POST /v2/validate runs format (well-formedness), structure (UBL 2.1 XSD) and semantic (rules + Schematron) layers. POST /v1/preflight checks canonical JSON invoice data. Existing POST /v1/validate clients retain the legacy JSON/XML compatibility contract. These are supported preflight checks, not guarantees of ASP acceptance or downstream filing.

Does the API submit my invoice to the FTA?

No. The API validates a document and returns findings. It is not FTA-accredited, does not transmit legal e-invoices, does not replace an accredited service provider and does not provide statutory archival.

Get your API key See pricing