Vergelijking
EDI of API: de technische verschillen
EDI wisselt complete zakelijke berichten uit als bestand in een gepubliceerde standaard, en bevestigt met een apart bericht. Een API handelt één verzoek tegelijk af in een formaat dat de aanbieder bepaalt, en bevestigt met een statuscode. Een orderstroom met een grote afnemer heeft meestal allebei: EDI naar de afnemer, een API naar je ERP.
Bijgewerkt op
Het korte antwoord
EDI en een API lossen hetzelfde probleem op, een order of factuur van het ene bedrijf naar het systeem van het andere krijgen, op een ander niveau. EDI is een uitwisseling van documenten: een bestand in EANCOM of een andere EDIFACT-variant, vaak met meer berichten tegelijk, en een apart bericht als bevestiging. Een API is vraag en antwoord: één order, één verzoek, één statuscode.
Welke van de twee geldt, bepaalt de partij aan de andere kant. Een afnemer die ORDERS, DESADV en INVOIC eist, bereik je via EDI. Een ERP, webshop of WMS bereik je via zijn API. Een EDI koppeling heeft daarom allebei: EANCOM naar de afnemer, API-verzoeken naar je eigen systemen.
EDI en API naast elkaar
| EDI | API | |
|---|---|---|
| Eenheid | Een bestand met één of meer berichten: één envelop kan 50 orders bevatten | Eén verzoek voor één record of één pagina resultaten |
| Formaat | EANCOM, een GS1-subset van UN/EDIFACT, ingevuld volgens de handleiding van de afnemer | JSON of XML, bepaald door de aanbieder van de API |
| Timing | Bestanden verstuurd zodra ze klaar zijn of op vaste tijden | Een verzoek wanneer de aanroeper wil, binnen de limiet |
| Bevestiging | Een apart bericht: CONTRL voor de syntax, APERAK voor de verwerking, ORDRSP voor de order |
De HTTP-status en het antwoord |
| Limieten | Tellers en referenties die moeten kloppen, vaste scheidingstekens | Verzoeken per minuut of per dag, paginagrootte |
| Toegang | AS2-certificaten, SFTP-sleutels of een postbus bij een netwerk | Een token bij elk verzoek, ververst als het verloopt |
| Wie het contract schrijft | De afnemer, in een implementatiehandleiding | De aanbieder, in zijn documentatie |
Hoe een EANCOM-bericht is opgebouwd, met envelop en tellers, staat in wat is EDI. Hieronder gaat het om wat er gebeurt als dat bericht in een systeem met een API moet landen.
Eén order, twee vormen
Een distributiecentrum bestelt 48 stuks van artikel 10482 bij Bakker Installatie B.V., af te leveren op 12 oktober. Als EANCOM-order, ingekort tot de regels die ertoe doen:
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+4500018236+9'
DTM+137:20261003:102'
DTM+2:20261012:102'
NAD+BY+8712300000018::9'
NAD+DP+8712300001237::9'
LIN+1++8712345104825:SRV'
QTY+21:48'
UNS+S'
CNT+2:1'
UNT+11+1'
En dezelfde order zoals de koppeling hem via de API in Exact Online aanmaakt:
{
"OrderedBy": "3f9a2c71-0b4e-4d8a-9c15-6e2d7a8b1f20",
"DeliveryAddress": "9b1e4d07-7c3a-4f62-8e95-0a4c2d6f3b18",
"YourRef": "4500018236",
"DeliveryDate": "2026-10-12",
"SalesOrderLines": [
{ "Item": "a8e3c5d2-1f4b-4c9a-8e7d-6b2a9f0c3d11", "Quantity": 48 }
]
}
Het EDI-bericht noemt alles bij een publiek nummer: GLN voor koper en afleverpunt, GTIN voor het artikel. De API van Exact wil interne verwijzingen: de id van de debiteur, van het adres en van het artikel. Daartussen zit het werk van de koppeling.
Vijf van de zes velden hebben in Exact een vaste plek. Drie gaan er ongewijzigd of met een ander datumformaat in, twee worden opgezocht: de debiteur heeft in Exact een veld GlnNumber, het artikel een veld Barcode. Het afleverpunt niet: een adres in Exact heeft geen GLN-veld. Een distributiecentrum met tien afleverpunten heeft tien GLN's onder één debiteur, en de koppeling houdt een vertaaltabel bij van GLN naar adres, of zet de GLN in een vrij tekstveld van het adres. Komt er een GLN binnen die er niet in staat, dan gaat de order naar een lijst ter controle in plaats van naar het hoofdadres van de debiteur.
Wat er gebeurt bij een fout
| Fout | EDI | API |
|---|---|---|
| Het bericht is onleesbaar | CONTRL met actie 4: het bestand of bericht is afgewezen |
Een 4xx-status met een foutmelding, niets verwerkt |
| De inhoud klopt niet | APERAK van de applicatie van de ontvanger, later |
Een foutmelding in het antwoord op dat verzoek |
| De ontvanger is bezet of plat | Het bestand wacht op de server of in de postbus | 429 of 5xx, de aanroeper wacht en probeert opnieuw |
| Hetzelfde bericht komt twee keer | Herkenbaar aan de referentie in UNB of aan het inkoopordernummer, als de ontvanger erop controleert |
Een tweede record, tenzij de koppeling eerst controleert |
| Er komt geen antwoord | Een ontbrekende CONTRL valt alleen op als iemand de bevestigingen bijhoudt |
Een time-out, direct zichtbaar |
De CONTRL zegt volgens de EANCOM-handleiding alleen iets over de syntax, niet over de inhoud; fouten bij het verwerken horen in een APERAK. Een bestand dat syntactisch klopt en een onbekende GTIN bevat, wordt dus geaccepteerd en blijft daarna liggen. Aan de API-kant zit het risico in de herhaling: een verzoek dat na een time-out opnieuw wordt verstuurd terwijl het eerste wel aankwam, maakt een tweede verkooporder. De koppeling bewaart daarom per inkoopordernummer welke verkooporder al bestaat, en schrijft niet opnieuw als het nummer er al is.
Doorvoer en limieten
Een rekenvoorbeeld met 50 orders die 's nachts binnenkomen, gemiddeld 12 regels per order.
Via EDI zijn dat 50 berichten in één envelop: 1 bestand binnen, en later 1 bestand met 50 orderbevestigingen terug.
Via de API van Exact Online, die 60 verzoeken per minuut en 5.000 per dag per administratie toestaat, hangt het af van hoe de koppeling zoekt. Zoekt hij elke regel los op, dan zijn het 50 × 12 = 600 opzoekingen plus 50 orders: 650 verzoeken. Bij 60 per minuut is dat 10 minuten en 50 seconden, en 13% van het dagbudget. Leest hij eerst de artikellijst in via een sync-endpoint, tot 1.000 artikelen per verzoek, dan kost een assortiment van 4.000 artikelen 4 verzoeken. Daarna zijn het 4 + 50 = 54 verzoeken, binnen één minuut en ruim 1% van het dagbudget.
De limiet zit dus niet in de EDI-kant maar in de API erachter. Hoe je met limieten rekent en wat er bij een 429 gebeurt, staat in wat is een rate limit.
Wat elk vraagt aan onderhoud
Een EDI-handleiding verandert zelden, en per afnemer. Een nieuwe afnemer betekent een nieuwe handleiding, een testronde en een eigen mapping: welke kwalificaties, welke codes, welke verplichte segmenten. Het vaste werk is bewaken: bij elk verstuurd bericht hoort een CONTRL, en elke APERAK moet door iemand of door een regel worden afgehandeld.
Een API verandert op het schema van de aanbieder. Tokens verlopen en worden ververst, limieten worden aangepast, velden komen erbij of verdwijnen. Het vaste werk is de aankondigingen volgen en de koppeling aanpassen voor de datum waarop iets stopt.
Wat dit betekent voor je koppeling
Wij bouwen en draaien beide kanten als één koppeling: de berichten van de afnemer gecontroleerd tegen zijn handleiding, je ERP of webshop bereikt via de API met een wachtrij en nieuwe pogingen, elke bevestiging gematcht en elke fout zichtbaar in het dashboard met het bericht of verzoek waar hij bij hoort. De vertaaltabel voor afleverpunten en de controle op dubbele orders horen daar vanaf het begin bij.
Hoe een EDI-stroom van order tot factuur loopt, staat op de EDI koppeling. Voor koppelingen op de API van je eigen systemen is er API koppeling laten maken. Vertel welke afnemer en welke systemen het betreft, dan hoor je wat er tussen de twee kanten nodig is.
Veelgestelde vragen
Wordt EDI vervangen door API's?
Niet zichtbaar. GS1 noemt miljarden EANCOM-berichten per jaar, en de standaard bestaat sinds 1989. Afnemers die een API aanbieden doen dat meestal naast hun EDI-programma. Welke van de twee je met een afnemer gebruikt, bepaalt wat die afnemer publiceert en eist.
Is EDI realtime?
Het transport kan snel zijn: over AS2 staat een bestand direct bij de ontvanger. Het proces is asynchroon. Een order gaat weg, de syntaxcontrole komt terug als CONTRL, een inhoudelijke fout als APERAK, en de orderbevestiging als ORDRSP. Bij een API komt het resultaat terug in hetzelfde verzoek.
Kan ik met een afnemer via een API koppelen in plaats van via EDI?
Als de afnemer daarvoor een API aanbiedt. Een afnemer wiens handleiding alleen EANCOM-berichten noemt, bereik je via EDI. Het werk aan jouw kant is in beide gevallen hetzelfde: de order van de afnemer moet een kloppende verkooporder in je ERP worden, met de juiste debiteur, het juiste afleveradres en de juiste artikelen.
Wat is het verschil tussen een CONTRL en een HTTP 201?
Een CONTRL is een apart bericht dat later binnenkomt en zegt dat een bestand de syntaxcontrole heeft doorstaan of is afgewezen. Het zegt niets over de inhoud. Een 201 komt terug in dezelfde verbinding en zegt dat dit ene verzoek is verwerkt en het record is aangemaakt.
Moet mijn ERP zelf EDI kunnen?
Nee. Een EDI-order kan buiten het ERP worden gecontroleerd en vertaald en daarna via de API van het ERP als verkooporder worden aangemaakt. Het ERP hoeft dan alleen de velden te hebben om op te zoeken: een GLN bij de debiteur en een EAN of GTIN bij het artikel. Zie de EDI koppeling en wat is EDI.
Vertel wat je nodig hebt
Vertel welke systemen je gebruikt en wat je wilt verbeteren. Je krijgt binnen één werkdag een persoonlijk antwoord. We helpen je de werkzaamheden helder te krijgen en spreken de prijs en planning af voordat je iets toezegt.
- Je weet de prijs en de doorlooptijd voordat je iets toezegt
- Wij zoeken uit welke koppeling het werk uit handen neemt
- Wij verzorgen de bouw, hosting, bewaking en het onderhoud
- Je team krijgt minder overtypwerk en minder uitzoekwerk