Pre-flight validators for legally mandated e-invoicing — validate before you submit.
Governments around the world now require digitally signed electronic invoices, cleared in real time by the tax authority. A rejected document means a broken sale, delays, and in some countries daily penalties. These keyless REST APIs let you validate an e-invoice before it reaches the authority: official XSD structure, country business rules, code lists, totals math and the digital signature — one POST /validate, no tax-authority account, no certificate, no onboarding.
| Country | Authority / regime | Mandate | API |
|---|---|---|---|
| 🇲🇾 Malaysia | MyInvois (LHDN / IRBM), UBL 2.1 XML & JSON | Phased, Phase 4 Jan 2026 | RapidAPI · Zyla |
| 🇩🇴 Dominican Republic | e-CF (DGII), Ley 32-23, signed XML | Phased, PYME wave running | RapidAPI · Zyla |
| 🇳🇬 Nigeria | NRS/FIRS Merchant-Buyer Solution (FIRSMBS), UBL 2.1 | Large taxpayers 1 Nov 2025 | RapidAPI · Zyla |
| 🇧🇴 Bolivia | SFV/SIAT (Impuestos Nacionales), signed XML + CUF | Final groups 1 Oct 2025 | RapidAPI · Zyla |
| 🇨🇷 Costa Rica | Comprobantes Electrónicos v4.4 (Hacienda / DGT) | All taxpayers 1 Sep 2025 | RapidAPI · Zyla |
Every API is available on two marketplaces — RapidAPI (free BASIC plan, tutorials) and Zyla API Hub (7-day free trial) — with full real example responses on both.
curl --request POST \
--url https://malaysia-myinvois-e-invoice-validator.p.rapidapi.com/validate \
--header 'Content-Type: application/xml' \
--header 'x-rapidapi-host: malaysia-myinvois-e-invoice-validator.p.rapidapi.com' \
--header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY' \
--data-binary @invoice.xmlThe verdict is always a structured JSON report (HTTP 200, "valid": true|false) with rule-coded findings you can act on:
{
"valid": false,
"errorCount": 2,
"findings": [
{ "level": "error", "ruleId": "MY-CORE-SUPPLIER-TIN",
"text": "Supplier TIN (PartyIdentification schemeID='TIN') is missing.",
"location": "cac:AccountingSupplierParty" }
]
}| Layer | Examples |
|---|---|
| Structure | Official XSDs published by each authority (UBL 2.1, e-CF v1.0, SIN schemas, Hacienda v4.4 — 8 document types incl. the new REP) |
| Country business rules | Nigerian TIN on both parties · per-line VAT · Malaysia mandatory fields · e-NCF ↔ document type consistency · Costa Rica ProveedorSistemas node |
| Control codes | 🇧🇴 CUF rebuilt from the header (SIN Módulo 11 + Base16, CUFD recovered) · 🇨🇷 the 50-digit clave numérica decomposed and cross-checked |
| Code lists | CABYS, MSIC, ISO-4217, condición de venta, medio de pago, unit codes… |
| Totals math | Line and document-level reconciliation (IVA, ITBIS, VAT) |
| Digital signature | Enveloped XAdES / XAdES-EPES / XML-DSig verified against the embedded certificate — document digest, SignedProperties, RSA-SHA256. Tampered documents are caught. |
- Keyless. No private key, no tax-authority credentials, no onboarding. Safe to call from CI, a save button, or a partner-onboarding gate.
- Stateless. The document is validated in-memory and discarded. No PII stored.
- Honest scope. These are informative pre-flight checks: trust chains to national CAs, live registry lookups and the actual clearance remain with the authority's online services. A
valid: truedoes not guarantee acceptance.
Developers, ERP/POS/SaaS integrators and Access Point Providers building e-invoicing (einvoice) compliance for Malaysia, the Dominican Republic, Nigeria, Bolivia or Costa Rica — anyone who wants to catch structural, code-list, totals and signature defects before the authority does.
APIs by Samir Chatwiti — Senior Software Consultant & Solution Architect (GovTech / LegalTech). Questions? Open an issue or use the Contact Provider button on any API page.