Beta

Validate electronic documents from your backend

One HTTP endpoint, 29 explicit validation targets, and the same validation core that runs behind the browser tools on this site. Send a document, name the rule set you want it measured against, read a report that says which layers ran and what each one found.

Read the quickstart

bash

curl https://edocumenttools.com/api/v1/validate \
  -H "Authorization: Bearer $EDOCUMENT_API_KEY" \
  -F "target=en16931-1.3.16-ubl-2.1" \
  -F "file=@invoice.xml"

A document that fails validation is answered with 200 OK and a report explaining why. A 4xx means the request was wrong, never that the invoice was.

json

{
  "apiVersion": "v1",
  "requestId": "req_5f2a91c4d0b7486e9a3c18bd7e04f562",
  "target": {
    "id": "en16931-1.3.16-ubl-2.1",
    "family": "generic",
    "version": "1.3.16"
  },
  "result": {
    "valid": false,
    "partial": false,
    "findingCount": 1,
    "checks": [
      { "layer": "XSD",     "status": "PASSED" },
      { "layer": "EN16931", "status": "FAILED" }
    ],
    "findings": [
      {
        "ruleId": "BR-CO-10",
        "severity": "error",
        "source": "EN 16931 1.3.16 (UBL)",
        "message": "Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount."
      }
    ]
  }
}

What it validates

Every rule package is committed to this project with a checksum and served from this origin, so a result cannot change because an upstream repository changed. Each target names the release it runs.

Generic UBL and EN 16931: 2 targets; 2.1, 1.3.16
France: 4 targets; 1.4.0.04
Factur-X: 3 targets; 1.09.2
Greece myDATA: 20 targets; 2.0.2

See every target, with its accepted document roots and stated limitations

The target is always yours to choose

There is no automatic profile detection, and that is a decision rather than a gap. Two official Greek schemas declare the same root element in the same namespace; a document can conform to one and not the other, and nothing inside it says which was meant. All UN/CEFACT CII releases share one namespace, so the release cannot be read from a document either.

An API that guessed would sometimes report a verdict against a rule set you never asked for, and you would have no way to tell that from a genuine failure. So the target id is required, it names a pinned release, and it never means "latest" — a document that validated against France_RFE 1.4.0.04 in January validates against 1.4.0.04 in December.

greece-mydata-2.0.2-invoicesdoc
greece-mydata-2.0.2-invoicesdoc-detailed

Two AADE contracts, two frozen ids, one root element. The caller decides which one the document is supposed to satisfy.

What happens to a document you send

The browser tools on this site never upload anything. The API works the other way round by definition — you send the document on purpose — so it is worth being exact about what happens to it.

Held in memory

No temporary file is written at any point, so there is nothing to delete afterwards and nothing a crash can leave behind.

Not retained

No document storage, no validation history, no findings database. The report goes back to you and the processing state is discarded.

Counted, not read

Per-day request and byte counts against your project. No filename, invoice number, party name, amount or finding text is recorded anywhere.

The privacy policy sets this out in full

Documentation

The full contract is published as an OpenAPI 3.1 document. A TypeScript SDK, @edocumenttools/sdk, is prepared for beta publication and is not yet available from npm. Until it is, the API is plain multipart over HTTPS and needs no client library — the quickstart shows what it takes with fetch alone.

What a passing report does not establish

Acceptance by a tax administration, a Peppol access point, a PDP or a recipient. This project contacts none of them and cannot transmit, clear or file anything.
Compliance with an e-invoicing mandate, which involves transmission, lifecycle statuses, reporting and retention — none of which can be observed in a file.
For Factur-X, PDF/A-3 container conformance. The embedded XML is validated; the container is not checked, and every report says so.

Developer and API Terms · Disclaimer