Supply Chain & Operations
EDI and API integration
Trading-partner integration is where supply chains actually touch each other. It is also where failures are silent: a document not sent is indistinguishable from a document not needed, until someone calls.
Why this breaks quietly
EDI and API integrations fail differently from applications. An application error is visible to a user. An integration error is a message that did not arrive, and nothing in the receiving system knows to expect it.
The result is a class of problem discovered externally — a customer chargeback, a carrier who never got the load tender, a 3PL shipping against stock that was already allocated. By then the transaction is days old.
The documents that carry the work
- 850 — Purchase Order
- Inbound demand from a customer. The document that starts most order-to-cash flows.
- 855 — PO Acknowledgement
- What you are actually committing to, including line-level changes. Frequently skipped, and a common source of dispute.
- 856 — Advance Ship Notice
- The shipment’s contents and hierarchy. Late or wrong ASNs are the single most common cause of retail compliance penalties.
- 810 — Invoice
- Settlement, and where mismatches against 850 and 856 become deductions.
- 940 / 945 — Warehouse ship order and advice
- The pair that governs 3PL execution. A missing 945 means inventory that is physically gone and systemically present.
- 204 / 214 — Load tender and status
- Transportation tendering and in-transit visibility, and the basis of most ETA reporting.
EDI, APIs, or both
This is rarely a choice. Large trading partners mandate EDI; marketplaces, carriers and modern platforms expose APIs; most estates run both indefinitely. The design question is whether they share one integration layer or grow separately.
- EDI — batch-oriented, standards-based, partner-specific in practice. Every partner interprets the standard slightly differently, so mapping is per-partner work regardless of what the specification says.
- APIs — synchronous or event-driven, better error semantics, but they shift the burden onto authentication, rate limits, versioning and retry.
- Shared integration layer — one place where mapping, validation, monitoring, retry and replay live, whatever the transport. Without it the same logic is reimplemented per partner and drifts.
What reliable integration requires
- Validation before acceptance. Structural and business-rule validation at the boundary, so bad data is rejected with a reason rather than absorbed.
- Idempotency. Partners resend. A duplicate 856 must not create a duplicate receipt.
- Retry with backoff, and a dead-letter path. Infinite retry against a permanently failing endpoint is an outage generator.
- Replay. The ability to reprocess a corrected message without manual re-keying.
- Monitoring on absence, not just errors. The dangerous case is the document that never arrived, so expected-volume alerting matters more than error rates.
- Acknowledgement discipline. Functional acknowledgements tracked and chased, not fired and forgotten.
Implementation approach
- Map the partner reality
- Which partners, which documents, which versions, which quirks. The specification is a starting point, not a description.
- Define the canonical model
- Translate partner formats into one internal shape. Without it, every partner change touches every system.
- Build observability first
- If it cannot be seen, it cannot be operated. This is the part most often deferred and most often regretted.
- Onboard partners incrementally
- One partner end to end beats ten partners half done.
- Plan for compliance testing
- Retail and carrier programs test before enabling, and the test cycle is usually longer than the build.
Next step
Talk about your integration landscape
Partner count, document types and where things currently go missing is enough to start.