Integrate VERI*FACTU without XML or certificates

This page is not an explanation of the regulation. It is about avoiding the most fragile part of implementing it. Your product keeps the order, subscription or payment; FiscalRail receives the commercial facts and becomes the invoicing system.

The integration you build

Use a JSON API over HTTPS to create customers, issue invoices and retrieve their state. You do not implement AEAT client-certificate authentication, SOAP requests or XML validation. FiscalRail owns that protocol and exposes stable objects, structured errors and idempotency, so a timeout does not create a second invoice.

Failures stop being special cases

• Before issuance: the API validates the invoice, required data and identification format. Fiscal checks become observable state, not a guess hidden inside a remote response.
• At issuance: FiscalRail assigns the number, calculates totals and stores the immutable invoice in one operation. Repeat a request whose result you lost with the same idempotency key and receive the original result.
• At submission: a temporary AEAT outage does not delete the invoice or block your worker. FiscalRail keeps the registration pending and retries delivery.
• When the outcome arrives: poll the invoice whenever you need it or receive a signed webhook for acceptances, issues and rejections. Deduplicate by event ID and retrieve the current state.

Exercise the contract before Live

The Test environment runs the same public invoice, QR, registration and webhook shape without contacting the AEAT. It includes deterministic accepted, accepted-with-errors, rejected and transient-retry outcomes, so your jobs and alerts do not debut in production.

When the flow is proven, the issuing taxpayer grants FiscalRail the required AEAT representation; FiscalRail verifies it before enabling Live issuance. The Live VERI*FACTU guide, testing guide and webhook guide contain the full contract.