Developer and API Terms

Version 2026-09-12 — effective 12 September 2026. This is the version recorded against your account when you accept these terms.

Scope

These terms govern the developer account, the developer dashboard and the Validation API at /api/v1. Everything else on this site — the browser tools, the reference pages — is governed by the Terms of Use, which continue to apply to you here as well. Where the two differ on a question about the API, this document governs.

The Privacy Policy describes what is done with personal data and with the documents you send. The disclaimer sets out the limits of a validation result. Neither is repeated here.

Accepting these terms is a condition of holding a developer account. If you do not accept them, do not create one; if you have one and no longer accept them, close it — the account page has the control, and closure is described below.

Beta status

The Validation API is in beta. That is a statement about expectations rather than about quality, and it means three things concretely:

• There is no service level agreement, no uptime commitment and no support commitment. None is offered, and nothing in these terms should be read as offering one.
• Interfaces may change while it is in beta, including in ways that require you to change your integration. The change policy below describes how that is done.
• Access is granted and may be withdrawn. Beta access is not a purchased right.

Beta does not mean the results are provisional. A validation runs the same pinned artefacts as the browser tools and reports the same findings; what is provisional is the service around it.

Your account

An account is held by a person, identified by an email address that has been confirmed. You are responsible for what is done with it, and specifically:

• Keeping the account credentials and every API key secret, and keeping the registered email address current and under your control. An address you no longer control is a route to your account, because it is the route a password reset takes.
• Everything done through your API keys, whether or not you did it. Requests are attributed to the key that made them; there is no other way to attribute them.
• Telling us promptly, through the contact form, if you believe a key or the account itself has been compromised. Revoking an exposed key yourself, immediately, is faster and you can do it without us.
• Not sharing an account. A second person needing access needs their own account; there is no arrangement under which two people share one set of credentials.

API keys

An API key is a server-side credential. The secret half is displayed once, at creation, and is stored only as a digest — it cannot be recovered, by you or by us.

You must not embed an API key in anything distributed to a device you do not control. That means no front-end JavaScript, no mobile application, no distributed desktop application, no public repository, and never in a URL. Anything shipped to a device can be read off that device, and a key so exposed is usable by anyone who finds it, against your allowance, until it is revoked. A key found to be publicly exposed may be revoked without notice; that is a protection for you and for the service, not a penalty.

Keys may be restricted to named validation targets. Revocation is immediate and permanent: a revoked key cannot be reinstated, and a replacement is a new key. Rotation is therefore create-deploy-revoke, in that order, which is also what avoids an outage.

Projects

A project groups the keys and usage of one integration. The number of projects and active keys an account may hold is set by its entitlement and is shown in the dashboard. Deleting a project revokes every key in it, immediately and irreversibly.

Project names are yours to choose and are visible only to you. They are not a place to put personal data, invoice identifiers or customer names.

Quotas and rate limits

Two separate mechanisms apply, and both are described in full in the documentation.

• A rate limit, per key, over a short window. Exceeding it is refused with rate_limited.
• A daily allowance, per account, resetting at 00:00 UTC. Exceeding it is refused with quota_exceeded.

A validation that the service executes counts against your allowance whether or not the document passes. A report saying a document is invalid is a result, not a failure to deliver one. Work that never started — a request refused because the queue was full — does not count.

Allowances are entitlements, not purchases. There is no billing, no credit balance and nothing to top up, and an allowance may be adjusted. These limits exist to keep a shared service usable and may be changed if a pattern of use makes that necessary.

Acceptable use

You may use the API for any lawful purpose, in commercial work included. You may not:

• Circumvent, or attempt to circumvent, a rate limit, a quota or a key restriction — including by creating multiple accounts to obtain more allowance than one account is given.
• Use the API in a way that degrades it for others, or in a way whose purpose is to test how much load it will take. If you need to know, ask.
• Attempt to gain access to another account, another account's keys, or any part of the service not exposed by the documented endpoints; or probe, scan or attack the service or the infrastructure it runs on.
• Upload content you have no right to process, or content whose processing would be unlawful.
• Resell or redistribute the API as a validation service of your own, or present its output as an official certification, an approval, or the work of a tax administration, a standards body or an approved platform. Using it inside a product of your own is fine; passing it off as yours or as official is not.
• Represent yourself as connected to, endorsed by or partnered with this project.

Automated access is the point of the API, so calling it from a program is expected rather than tolerated. What is not acceptable is automation that ignores the refusals: a client that retries a 429 without waiting, or retries a permanent 4xx in a loop, is generating load that answers nothing.

Suspension and termination

An account, a project or a key may be suspended or revoked where there is a breach of these terms, where a credential appears to be compromised, where use is degrading the service for others, or where the law requires it. Where it is practical to warn you first, you will be warned first; where a credential is exposed or the service is at risk, action comes first and the explanation follows.

You may close your account at any time from the account page. Closure revokes every key immediately, removes your projects from the dashboard and signs you out everywhere. It cannot be undone, and what survives it is described in the Privacy Policy — read that before closing, because the answer is not "everything is erased".

Beta access may also end for everyone, if the API is withdrawn. You would be told before that happened, at the registered address.

Availability

The API is provided as it is. There is no guarantee that it will be available, that it will answer within any particular time, or that any particular endpoint, target or field will continue to exist. It runs on a single managed instance that also serves this website, and it can be unavailable for maintenance, for capacity, or because something broke.

Requests are refused rather than queued indefinitely when there is no capacity. A refusal is not a failure of the service in the sense these terms are concerned with; it is the service declining work it cannot do.

Versioning and change

The API is versioned in its path: /api/v1. The following are what you can rely on within a version.

• Target ids are frozen. A public target id names a specific rule-set release and is never re-pointed at a different one. A new release gets a new id.
• Machine-readable error codes are stable. The code field is the contract. The human-readable title and detail are not, and may be reworded at any time.
• Rule identifiers are as the rule package states them. They are never rewritten or invented. Finding message text is the rule package's own and can change when the package does.
• Fields may be added to a response without notice. Parse defensively: an unknown field is not an error.

A target may be deprecated and eventually withdrawn — because a rule package is superseded, because an issuer withdraws it, or because it can no longer be executed correctly. Where there is a choice, a deprecated target is announced in the documentation and kept working for a reasonable period. Where an issuer's change forces our hand, it may not be possible to give notice.

A rule package update can change what a validator reports about a document that has not changed. That is a property of pinned rule sets rather than a defect: the new package is a different target with a different id, and the one you pinned keeps answering as it did.

Documents you send

An uploaded document is processed in memory and discarded. No temporary file is written, no document is retained, no validation history is kept, and no finding is stored. What is retained is a per-day count of requests and bytes against your project — numbers that would be identical had you validated an empty file.

You keep every right in the documents you send. No licence to them is asked for or granted beyond what is needed to process the one request: read the bytes, run the validation, return the report, discard the state. Nothing is used to train anything, and nothing is shared.

You are responsible for having the right to send what you send, and for whatever obligations attach to it. The Privacy Policy describes the processing in the terms data-protection law uses.

What a validation result is, and is not

A report is the output of published validation artefacts — XML Schemas and Schematron rule packages issued by standards bodies and, for France, by the FNFE-MPE — pinned to the version the target names, run against the bytes you sent. It is a technical result, and it establishes nothing beyond itself.

• It is not acceptance by any authority. Not by a tax administration, not by the DGFiP, AADE or Chorus Pro, not by a PDP or an approved platform, not by a Peppol access point, and not by your recipient. This project contacts none of them and cannot transmit, clear, report or file anything.
• It is not a compliance guarantee. Compliance with an e-invoicing mandate involves transmission, lifecycle statuses, reporting obligations and retention, none of which can be observed in a file.
• It is not a certification, and this is not a certified, approved or official validator. It is not operated by, endorsed by or affiliated with any administration or standards organisation.
• Some checks are not performed, and the report says which. PDF/A-3 container conformance is the clearest example: a Factur-X target validates the XML inside the PDF and states on every result that the container was not checked. For Greece, the AADE business rules are not checked at all.
• A clean result is not a promise of correctness. Validation artefacts contain errors, this implementation may contain errors, and a rule that did not fire is not proof that what it tests is right.

You remain responsible for what you submit to a platform, a customer or an administration.

Warranty and liability

The API is provided without warranty of any kind, express or implied, including any implied warranty of merchantability, fitness for a particular purpose or non-infringement. To the extent permitted by law, the operator is not liable for any loss arising from use of the API, from reliance on its output, from its unavailability, or from the loss or exposure of a credential you were responsible for keeping.

This limits liability. It does not excuse an incorrect technical claim: if the API states something about a document that is wrong, that is a defect to be fixed, and reporting it is welcome. Nothing here excludes liability that cannot lawfully be excluded, and nothing here restricts your rights as a consumer under mandatory law.

Intellectual property

The API, this site's code, its documentation and its text belong to the operator. The standards, schemas and rule packages the API executes belong to their respective issuers and are used under their own licences; those are listed with their versions in the project's third-party notices. Nothing in these terms transfers any right in them to you, or in your documents to us.

You may reproduce the output of a validation of your own document freely — it is a statement about your document.

Changes to these terms

These terms may change. Each version carries a date, and that date is what is recorded against your acceptance. A material change means a new version and a new acceptance: you will be asked to accept it, and the record of what you accepted before is kept rather than overwritten. The current version is always the one on this page.

Governing law

These terms are governed by the law of the operator's place of establishment, without prejudice to mandatory consumer protections that apply where you live. Who operates this site is on the legal notice.

Contact

The contact form is the channel for questions about these terms, for reporting a defect, for asking about an allowance, and for anything else about the API. Quote the requestId from a response when you are reporting something that went wrong with a specific request — without it, a report cannot be located in the operational log.

Do not send documents through the contact form. It accepts no attachment, and a contact message is ordinary email travelling through mail servers — which is exactly what the API exists to avoid.