If you sell to more than a handful of large partners, you will eventually be asked to support both X12 EDI and a direct API integration. The two look like competing choices. In practice they are rarely a choice at all, because the partner decides which one you use, and a distributor selling into several channels usually ends up running both.
What matters is understanding why each exists, so you can tell which conversations are worth having and which are not.
What X12 EDI actually is
ANSI X12 is a document standard. It defines a set of numbered transaction sets, each representing a business document: an 850 is a purchase order, an 855 acknowledges it, an 856 announces the shipment, an 810 invoices for it, and a 997 confirms a file was received. Each one has a defined structure, and the numbers mean the same thing across every partner who uses them.
Two things about X12 surprise people coming from an API background. First, the standard defines the document, not the delivery. The same 850 can arrive over AS2, SFTP or a value-added network, depending on what the partner supports. Second, standardization is narrower than it sounds. The transaction set numbers are fixed, but each partner’s implementation guide sets its own required fields and business rules within that standard, which is why two partners using the same 856 can still have different requirements.
EDI is also batch-shaped by nature. Documents are exchanged as files, often on a schedule, and the response is a separate document rather than an immediate answer. That is a feature in the context it was designed for: a durable, auditable record of exactly what each side sent.
What an API integration is
An API integration calls the partner’s service directly and gets an answer back in the same exchange. You ask for orders, you get orders. You post a shipment, you find out immediately whether it was accepted and why not.
The practical differences follow from that. Errors surface at the point of the call rather than in a response document hours later. Data is current rather than as of the last batch. And the integration is usually richer, because an API typically exposes operations that have no EDI equivalent at all, such as listing management, repricing or fee lookups.
The cost is that APIs are specific to the partner and they change. An API integration is a dependency on someone else’s versioning, and the partner can deprecate an endpoint on their own timeline.
Why partners pick one or the other
Large retailers with long-established supply chains run on EDI because their internal systems were built around it and their partner base already supports it. The standard is stable, it is auditable, and it does not require every supplier to write code against a proprietary interface.
Newer platforms, and marketplaces in particular, lead with APIs because the relationship is not only purchase orders and invoices. A marketplace needs you to manage listings, inventory, pricing and fulfilment, and most of that has no transaction set.
This is why the question is rarely yours to answer. If a partner runs on X12, implementing their documents is faster than negotiating an exception.
Amazon runs both, in different programs
Amazon is the clearest example, because it uses both models in parallel depending on how you sell.
Vendor Central, where Amazon buys wholesale from you, runs on EDI. Purchase orders, acknowledgments, ship notices and invoices move as transaction sets, with a routing exchange on collect shipments, and we cover that in Amazon EDI integration. If the two Vendor Central programs are new to you, what Amazon EDI is walks through which documents each one exchanges. Each program also has its own page: Amazon Vendor Central Wholesale EDI for stock Amazon buys outright, and Direct Fulfillment EDI for dropship orders for orders you ship straight to the customer. For how those connections run day to day inside an ERP, including how rejections are traced, see Amazon Vendor Central EDI inside your ERP.
Seller Central, where you sell on the marketplace yourself, runs on SP-API. That covers orders, inventory, fulfilment, reports and automated repricing via approved APIs, and none of it has an EDI equivalent. We cover that side in Amazon SP-API integration.
A company doing both is running two integrations into the same product catalogue. Amazon’s program requirements and API versions change over time, so check the current spec for whichever program you are implementing rather than relying on how it worked at a previous onboarding.
Running both in one ERP
The failure mode here is not technical. It is letting the two paths become two systems.
When EDI is handled by one tool and APIs by another, you get two copies of your inventory position, two definitions of an order, and a reconciliation problem that grows with every partner. The symptom is familiar: someone exports a spreadsheet to work out what the real stock figure is.
The alternative is to treat transport as an edge concern. An 850 arriving as a file and an order arriving from an API call are both inbound orders, and both should land in the same order table with the same validation. A shipment going out as an 856 and one going out as an API call are both shipments against the same record. What differs is the adapter at the boundary, not the business object behind it.
That is the approach we take with EDI integration and with marketplace integration: one ERP holding the orders, the inventory and the shipments, with partner-specific adapters at the edges. Where no existing system fits, that ERP is built through custom ERP development. A US consumer electronics brand we work with runs both models at once, with Amazon Vendor Central and Adorama on direct EDI, other retailers on EDI through SPS Commerce, CommerceHub or Radial, and marketplaces such as Walmart over APIs.
How to decide
Start by asking the partner, because in most cases they have already decided. If they run on X12, you are implementing their implementation guide.
Where you genuinely have a choice, two questions settle it. Does the relationship involve anything beyond orders, shipments and invoices? If it involves listings, pricing or fulfilment control, you need an API. Is an auditable record of exactly what each side sent important to the relationship? EDI gives you that by design, because the documents are the record.
Then ask the question that outlasts both: where does the data land? A partner integration that writes into your existing order and inventory records is an addition to your system. One that keeps its own copy is a second system you now maintain.
If you are weighing up a new partner requirement, or you are already running EDI and APIs in separate tools and feeling the reconciliation cost, we can look at what consolidating into the ERP would involve. See EDI integration services for how that work is structured, or get in touch with the partners and programs you need to support.
Common questions
Can one ERP handle both X12 EDI and API partners?
Yes, and most distributors end up needing to. The transport differs but the destination does not: both paths should write to the same order, inventory and shipment records rather than maintaining separate copies.
Is an API integration always better than EDI?
No. The partner decides. A retailer running on X12 will not accept API calls, and asking for an exception is slower than implementing the documents they already support.
Does EDI require a VAN?
Not necessarily. X12 is a document standard, not a delivery method, and it can move over AS2, SFTP or a VAN depending on what the partner supports. Check the partner's current connectivity options.