Connect the XEDI API to EDI instantly
Join thousands of businesses moving EDI orders, invoices and fulfilment updates between the XEDI API and their trading partners on XEDI, no manual re-keying.
No credit card needed ✦ Free EDI mailbox included
Getting started with the XEDI API EDI
The XEDI API gives your own systems direct access to your trading data: documents, their status, the partners they went to and what came back, at a finer grain than any file or portal view provides.
One managed platform, no custom code
XEDI maps the XEDI API to your trading partners and validates every document, so data flows straight into the systems your teams already use.
This is the third way of working with us, not a different product
There are three ways to use XEDI and they suit different businesses. The portal is a place your team works, which is enough for a great many companies. An integration connects your ERP or warehouse system so documents move without anyone touching them. The API is for when neither of those is granular enough.
It exists because larger operations want their own systems to hold the truth. A planning tool that needs order data as it arrives, a reporting layer that needs delivery confirmation, a customer service screen that needs to show where a document is: those want data, not documents in a folder.
What stays ours is the part that is genuinely hard
Using the API does not mean taking on EDI. The partner connections, their requirements, the validation, the formats and the work of keeping all of it current stay with us exactly as they would otherwise. What changes is how your side reaches the data.
That distinction matters because the difficult part of EDI is not moving a file. It is that every retailer wants something slightly different and changes it without much notice. Keeping that with us means your developers build against one stable interface rather than against a moving set of partner specifications.
What your team sees day to day
Your systems query what they need when they need it, and the portal remains available for anybody who wants to look at a document rather than consume one.
The underlying chain is unchanged: partner orders arrive, the despatch advice is raised from what ships with SSCC labels where required, and the invoice follows delivery with its arrival confirmed. The API exposes each of those states as they happen.
Most businesses using the API also run an integration, because the two answer different questions. The integration keeps a system of record in step; the API feeds everything else.
Documents you can exchange
- Orders received from trading partners
- Acknowledgements, despatch advice and invoices you send
- Document status and delivery confirmation
- Partner and connection detail
- Exceptions and validation results
Built for the XEDI API teams
Whoever owns the XEDI API in your business, XEDI keeps EDI accurate and hands-off.
- Enterprise integration teams
- Businesses with their own middleware
- Data and analytics teams
- Software vendors building on top
- Operations wanting real-time document visibility
the XEDI API EDI document types
The API exposes the same documents that move through the platform, plus the state around them.
| Document | What it carries | Direction |
|---|---|---|
| Inbound documents | Orders and other partner-originated messages, available as structured data as they arrive. | Partner to your systems |
| Outbound documents | Acknowledgements, despatch advice and invoices submitted by your systems for validation and delivery. | Your systems to partner |
| Document status | Where a document is: validated, sent, acknowledged or rejected, with the reason attached. | XEDI to your systems |
| Delivery confirmation | Confirmation that an invoice or despatch advice reached the partner, not merely that it was sent. | XEDI to your systems |
| Partner and connection detail | Which partners you are connected to and what each of them exchanges. | XEDI to your systems |
| Exceptions | Validation failures and partner rejections, with enough detail for your systems to act rather than alert. | XEDI to your systems |
How to connect the XEDI API with EDI using XEDI
The API is usually adopted alongside an existing integration rather than instead of one. The sequence below is what onboarding looks like from your side.
-
01
We establish what your systems need to read and write, and at what frequency.
-
02
We issue credentials scoped to your data and the operations you actually need.
-
03
Your developers build against the API while we continue running the partner connections underneath.
-
04
We prove the flows end to end, including how your systems should behave when a partner rejects something.
-
05
You get direct access to your trading data, with the partner relationships still managed by us.
Ready to connect the XEDI API?
Talk through documents, mapping, testing and go-live with XEDI.
Everything about the XEDI API EDI
Common requirements
- Which systems will consume the API
- What they need to read and write
- Expected volume and frequency
- How your systems should handle exceptions
- The trading partners in scope
What we need from you to build it
Only what we cannot decide for you. Nothing here involves partner specifications, which remain ours.
- Consuming systems
- Which of your systems will call the API and what each needs, since scope and credentials follow that.
- Read and write scope
- Whether your systems only need to read, or will also submit documents, because the two have different implications.
- Volume and frequency
- How often you will poll or how much you expect to move, so limits and patterns can be agreed rather than discovered.
- Exception handling
- What your systems should do when a partner rejects a document, since an unhandled rejection is worse than no automation.
- The trading partners in scope
- Which relationships the data covers. Their requirements remain ours to maintain.
Why suppliers choose XEDI for the XEDI API
- Your partners are generally connected already, so developers can build against real trading data from the start.
- Your systems hold the data at the grain they need, without your developers learning EDI standards.
- Partner requirements, validation and connections stay ours, so you build against one stable interface.
- Delivery confirmation is available as data, not just as something visible in a dashboard.
- It runs alongside the portal and an integration rather than replacing either.
- When a partner changes what they require, that is our problem and your interface does not move.
Do we need the API if we already have an integration?
Often yes, because they answer different questions. The integration keeps your system of record in step; the API feeds planning, reporting and customer-facing tools that need the data at a finer grain.
Does using the API mean we handle EDI ourselves?
No. Partner connections, their requirements, validation and formats remain ours. What changes is that your systems reach the data directly rather than through documents or a screen.
Can we submit documents as well as read them?
Yes. Outbound documents can be submitted by your systems and are validated against the partner's requirements before they leave, exactly as they would be from any other route.
Plan your the XEDI API EDI setup
Everything you need to scope, map and go live with the XEDI API, in one place.