EDI concepts
EDI vs API: the technical differences
EDI exchanges complete business documents as files in a published standard, and confirms receipt with a separate document. An API handles one request at a time in a format its publisher defines, and confirms with a status code. Most order flows with a retailer use both: EDI toward the trading partner and an API toward the ERP or the store.
Updated
The short answer
EDI and an API solve the same problem, moving an order or an invoice between two companies' systems, at different levels. EDI is a document exchange: a file in X12 or EDIFACT, sent in batches, with a formal acknowledgment document. An API is a request and a response: one order, one call, one status code.
The trading partner decides which one applies. A retailer that requires an 850, an 856 and an 810 is reached by EDI. An ERP, a store platform or a warehouse system is reached by its API. An EDI integration therefore has both: X12 on one side, API calls on the other.
EDI vs API in one table
| EDI | API | |
|---|---|---|
| Unit of exchange | A file with one or many documents: one interchange can hold 50 orders | One request for one resource or one page of results |
| Format | X12 or EDIFACT, a published standard, narrowed by each partner's guide | JSON or XML, defined by the publisher of the API |
| Timing | Files sent when ready or on a schedule | A call whenever the caller makes it, within the rate limit |
| Receipt | A separate document: the 997 for syntax, an 824 for content | The HTTP status and the response body |
| Limits | Counts and control numbers that have to match; delimiters and file names where the partner fixes them | Calls per minute or hour, page size, date range |
| Authentication | AS2 certificates, SFTP keys or a network mailbox | A token sent with every call, refreshed when it expires |
| Who writes the contract | The larger trading partner, as an implementation guide | The publisher of the API, as documentation |
The table holds for one partner and one process. Walmart is a useful case because it documents both for its drop-ship vendors, checked on 3 October 2026 in its EDI interface and DSV Order Management API pages.
One order acknowledged both ways
The order from our EDI 850 page, PO 4500018236 with 24 units on line 1 and 16 on line 2, acknowledged to Walmart by EDI:
ST*855*0001~
BAK*00*NA*4500018236*20260928~
PO1*1*****PL*1~
ACK*IA*24*EA~
PO1*2*****PL*2~
ACK*R4*16*EA~
CTT*2~
SE*8*0001~
And by API:
POST /v3/orders/4500018236/acknowledge?shipNode=123456701 HTTP/1.1
Host: api-gateway.walmart.com
WM_SEC.ACCESS_TOKEN: eyJraWQiOi...
WM_QOS.CORRELATION_ID: 16338294-795c-44eb-97cd-37967f8532e5
Accept: application/json
The differences are in the detail. The 855 answers per line: IA accepts line 1, R4 rejects line 2 as not available, and CTT01 and SE01 carry the counts 2 and 8 that the receiver verifies. The API call has no body. It acknowledges all lines of the order, and a line that cannot ship is cancelled with a second call. The 855 travels in a file named WMI_855PR_... with any number of other acknowledgments; the API call carries a new correlation ID each time and is one of a limited number of calls.
The result comes back differently as well. The API returns 200 with the order object and its line statuses in the same exchange. The 855 is answered by a 997 file, and a content error arrives in an 824 whose message in TED02 can be truncated at 60 characters.
Throughput and limits
A batch shows the difference in arithmetic. Take 50 orders that arrive overnight.
By EDI the 50 purchase orders are 50 ST to SE sets in one interchange: 1 file in, 1 file with 50 acknowledgments out. Walmart's own 855 sample holds 10 transaction sets in one group, closed with GE*10.
By API the same 50 orders are 1 retrieval call, since a page holds up to 200 orders, and 50 acknowledge calls. Walmart throttles hourly and daily allotments, returns 429 Too Many Requests when they are exceeded, and reports the remaining allotment in the headers X-Current-Token-Count and X-Next-Replenishment-Time. Its documentation explains the replenishment with an example: if 20 calls are available every hour, one call becomes available every three minutes once they are used. With that example allotment, 20 of the 50 acknowledgments go out at once and the other 30 follow at one per 3 minutes: 90 minutes. The real allotment differs per API; the mechanism is the same.
Other documented limits on the API side: retrieval reaches back 180 days, a page holds at most 200 orders, a bulk download at most 20,000. On the EDI side the limits are structural: delimiters fixed at ~, * and >, a file name with the GMT date, time and a six-digit random number over SFTP, and control numbers that have to pair up. How to plan around call limits is worked out in API throttling and backoff.
What happens on failure
| Failure | EDI | API |
|---|---|---|
| The message is malformed | The 997 rejects the set or the group; nothing is processed | A 4xx status with an error body; nothing is processed |
| The content breaks a rule | An 824 arrives later and names the order and line | An error code in the response to that call |
| The receiver is busy or down | The file waits on the SFTP server or in the mailbox | 429 or 5xx; the caller has to wait and retry |
| The same message is sent twice | Recognized by the interchange control number or the PO number, if the receiver checks | A second record, unless the call is idempotent |
| No answer comes back | A missing 997 has to be noticed by matching acknowledgments | A timeout, visible at once |
Two rows need active handling. A file that is accepted on the 997 and wrong in content looks fine for hours, so the 824 has to be read and matched to its order. And a retried API call that the first time did arrive creates a second order unless the integration checks before it writes. Walmart's API states the rule from its side: only orders in status Created are acknowledged, and an order with a shipped or cancelled line is not acknowledged again.
Where EDI and API meet
In practice the choice is rarely one or the other. The retailer sends X12, and the system that has to hold the order has an API.
The two sides run at different speeds. The EDI side delivers 50 orders in one file and expects one file back. The API side accepts them one call at a time and slows the caller down when a limit is reached. A queue between them stores each order from the file, creates it through the API, retries with a growing pause after a limit error, and builds the outbound 855 only from orders the ERP confirmed. Which streams run per event and which in batches is covered in real time vs batch.
The mapping work is on both sides too. Toward the partner it is the guide: which qualifier, which code, which hierarchy. Toward the ERP it is the data model: the partner's item number to your SKU, its location code to an address, cases to eaches. That part is described under EDI mapping.
What each asks in upkeep
EDI guides change rarely and per partner. A new partner means a new guide, a test cycle with ISA15 set to T, and a mapping of its own. The standing work is monitoring: every outbound document needs its 997, and every 824 needs a person or a rule.
APIs change on their publisher's schedule. Walmart's developer portal keeps a page of recent releases and planned deprecations per API. Tokens expire and are refreshed, limits are adjusted, and fields are added. The standing work is following those announcements and adjusting before the date.
We build and run both sides as one integration: the partner's documents validated against its guide, the ERP or store reached through its API with a queue and retries, each acknowledgment matched, and each failure shown in the dashboard with the document or call it belongs to. For a store on Shopify the route is described under Shopify EDI integration. Tell us which partner and which systems are involved.
Frequently asked questions
Is EDI being replaced by APIs?
The two run side by side. X12 has been chartered by ANSI for more than 40 years and GS1 reports billions of EANCOM messages a year. Retailers add APIs next to their EDI programs: Walmart documents an EDI interface and a REST API for the same drop-ship process. Which one you use with a partner is decided by what that partner publishes and requires.
Is EDI real time?
The transport can be fast: AS2 pushes a file to the partner the moment it is sent. The process is asynchronous. A document goes out, the syntax acknowledgment (997) comes back as a second file, and a content error comes back as a third, such as the 824. An API call returns its result in the same exchange, within its rate limits.
Can I connect to a retailer by API instead of EDI?
When the retailer offers one for your program. Walmart's drop-ship vendors can acknowledge, ship and cancel orders through the DSV Order Management API. A partner whose guide names only X12 documents is reached by EDI. Either way the work on your side is the same: the partner's order has to become a correct record in your ERP.
What is the difference between a 997 and an HTTP 200?
A 997 is a document that arrives later and says a file passed the syntax check, per functional group and per transaction set. An HTTP 200 arrives in the same connection and says this one request was processed. A 997 does not say the content was accepted; a 200 on an order call usually does.
Do Shopify and NetSuite speak EDI?
They expose APIs. Neither has an X12 or EDIFACT translator of its own, so a retailer's 850 is translated and mapped outside the platform and created through its API. See Shopify EDI integration and NetSuite EDI integration.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase