API vs EDI: practical decision tree

The "should we do EDI or APIs" debate is only useful if the right criteria are posed. This page proposes five questions to ask in order, and a pragmatic decision tree to orient a context-aware choice.

A wrong opposition

The "modern API vs legacy EDI" opposition is poorly framed. EDI and REST APIs are two technical families that overlap partially: an EDIFACT message can travel over HTTPS POST, a REST API can carry a UBL payload just as well as a proprietary JSON. The real topic is not the writing format (XML vs JSON vs segments) nor the transport (AS2 vs HTTPS), but rather: who is the partner, what constraints weigh on the exchange, and how to minimise TCO over the flow's lifetime. See also the article EDI in the API era for the extended discussion.

Criterion 1: who is the partner

The first question is about the partner and their technical preferences. Five cases dominate:

• Retail hub or automotive OEM with proprietary spec — the decision is almost always made: the partner imposes the format (X12, EDIFACT, sometimes VDA), the transport (AS2 or OFTP2) and the MICs. The choice reduces to respecting the partner spec.
• Public buyer or European public invoicing — PEPPOL BIS Billing 3.0 / EN 16931 is probably the mandatory route, with AS4 eDelivery as transport. The classical REST API does not apply.
• E-commerce marketplace or B2B SaaS — REST API/webhook is the norm, often with public OpenAPI and official SDK. Classical EDI does not apply.
• SME supplier or service provider — often no strong preference; the choice should minimise their integration cost (so often REST API if the partner is modern, or a simple web portal if IT investment is low).
• Bank or financial institution — often ISO 20022 over EBICS/SWIFT, sometimes SFTP. REST API is progressing via Open Banking mandates (PSD2 in Europe, national equivalents) but coexists with established protocols.

Criterion 2: is there a regulatory mandate

If a regulatory mandate imposes a specific format or transport, the decision is locked. Notable examples in 2026: ViDA in Europe (EN 16931 mandatory for intra-EU from 2030), HIPAA in the US (X12 5010 mandatory for claims/remittance/eligibility), Italy SdI (FatturaPA XML mandatory for B2B/B2G/B2C), Spain SII (mandatory transactional reporting for VAT), Poland KSeF (FA(2) mandatory for B2B), France PPF/PDP (2026-2027 timeline), Saudi Arabia ZATCA (FATOORA), Mexico CFDI 4.0, etc.

With a mandate in place, the choice reduces to compliance: what imposed format, what accepted transport, what timeline. Technical latitude lives in the internal architecture, not the external contract.

Criterion 3: what exchange frequency

Frequency changes the expected operational profile. Three orders of magnitude:

• Very high frequency (millions of transactions per day, sub-second latency) — REST/gRPC API or event messaging (Kafka). Traditional EDI protocols (batch AS2) become irrelevant.
• Normal frequency (hundreds to tens of thousands of transactions per day, latency acceptable in seconds to minutes) — EDI or REST API are both viable; the choice is made on other criteria.
• Low frequency or batch (a few transactions per day or week, latency acceptable in hours) — batch EDI (AS2, SFTP) remains optimal: operational simplicity, low cost, proven traceability.

Criterion 4: shared or proprietary semantics

When you exchange with a partner for the first time, shared semantics are decisive. EN 16931 and PEPPOL BIS Billing 3.0 impose a common vocabulary across all member states: your invoice is automatically interpretable by any compliant recipient. EDIFACT and X12 rely on public implementation guides: semantics are traceable but require interpretation work. Conversely, a public REST API is a proprietary vocabulary (yours or the partner's): every integration is a specific onboarding project.

If the ecosystem includes many partners (typical of retail, public sector, European B2B invoicing), standardised shared semantics (EDIFACT, X12, EN 16931) minimise onboarding cost. If the ecosystem has few stable bilateral partners, a proprietary REST API may be more economical.

Criterion 5: contractual requirements

Four contractual requirements can weigh on the choice:

• Cryptographic non-repudiation: AS2 (signed MDN) and AS4 (signed receipt) embed non-repudiation-of-receipt (NRR) proof that does not natively exist in a REST API. For legal flows (invoices, contracts), this is often decisive.
• Long-term archival: EDI flows are historically archived in stable formats (XML, segments) that outlive platform generations. JSON API payloads archive just as well but require pinning the schema at archival time.
• Strict contractual SLA: mature EDI protocols (AS2, OFTP2) offer observable and negotiable SLAs that are harder to guarantee on a public REST API (rate limit, throttling, versioning).
• Strong sovereignty or confidentiality: some verticals (defence, critical energy, healthcare) exclude public cloud architectures, which may favour AS2 over a private VPN or OFTP2.

The decision tree summarised

The pragmatic sequence to follow, in this order:

1. Does the partner impose a technology or format? → if yes, respect the partner spec.
2. Is there a regulatory mandate? → if yes, respect the mandate (often EDI or standard XML).
3. Is the frequency very high with sub-second latency? → if yes, REST/gRPC API or event messaging.
4. Does the flow require cryptographic non-repudiation or long-term legal archival? → if yes, EDI (AS2/AS4 or equivalent).
5. Does the ecosystem have many heterogeneous partners? → if yes, standardised EDI (EDIFACT, X12, EN 16931). Otherwise a proprietary REST API is viable.

Further reading

• EDI in the API era — the extended convergence discussion.
• Modern integration architecture — the global architectural framework.
• PEPPOL vs bilateral — an important particular case of the same tree.