Connect Azure Blob Storage to EDI instantly
Join thousands of businesses moving EDI orders, invoices and fulfilment updates between Azure Blob Storage and their trading partners on XEDI, no manual re-keying.
No credit card needed ✦ Free EDI mailbox included
Getting started with Azure Blob Storage EDI
XEDI exchanges trading files through Azure Blob containers, with the access tier and credential lifetime settled deliberately, because both of those decide whether an exchange keeps working unattended.
One managed platform, no custom code
XEDI maps Azure Blob Storage to your trading partners and validates every document, so data flows straight into the systems your teams already use.
Access tiers are a cost feature that becomes a retrieval problem
Blob storage offers tiers from hot down to archive, and the saving on the colder ones is real. It is also easy to apply a tiering policy to a storage account without thinking about which containers it touches.
Archive is the one that bites. A blob in the archive tier is not readable until it has been rehydrated, and rehydration is measured in hours rather than seconds. During a dispute about what was sent to a retailer, that is the worst possible moment to find out. The tier applying to exchange containers is therefore established explicitly.
Credentials that expire are the other recurring failure
Shared access signatures are the usual way to grant scoped, temporary access, and temporary is the operative word. An exchange configured with a signature valid for a year works perfectly for a year and then stops, typically without anybody having diarised it.
So the lifetime is agreed and the expiry is known rather than discovered. Where your policy allows a managed identity instead, that avoids the problem altogether, and which route applies depends on what your platform team permits rather than on what is technically neatest.
What your team sees day to day
You get an EDI mailbox and a portal that behaves like an inbox, showing collection state without anyone browsing a container.
Orders arrive and become the despatch advice raised from what is actually going, adjusted where quantities differ, with SSCC pallet labels where required, and the invoice follows delivery with its arrival confirmed in the dashboard.
Your Azure estate is unchanged: the EDI capability is bolted onto storage your organisation already governs, and the partner requirements behind it remain ours.
Documents you can exchange
- Order files written to a container for your systems
- Despatch and quantity files collected from a container
- Invoice data written out for downstream processing
- Stock and catalogue files exchanged with partners
- Failed documents written for correction
Built for Azure Blob Storage teams
Whoever owns Azure Blob Storage in your business, XEDI keeps EDI accurate and hands-off.
- Azure platform and infrastructure teams
- Businesses standardised on Microsoft cloud
- Finance and operations consuming exported data
- Organisations with strict credential policies
- Enterprises with existing Azure governance
Azure Blob Storage EDI document types
A container carries blobs; these are the exchanges they usually serve.
| Document | What it carries | Direction |
|---|---|---|
| Order files | Retailer demand written to a container path your systems already consume. | XEDI to Blob |
| Despatch files | What is shipping, collected from the container and validated before becoming a despatch advice. | Blob to XEDI |
| Invoice data | Invoice detail written out for downstream finance or reporting use. | XEDI to Blob |
| Catalogue and stock files | Product and availability figures exchanged with partners on an agreed cycle. | Either direction |
| Archived blobs | Handled files moved aside, at a tier that still permits retrieval when somebody asks. | Within the container |
| Exception blobs | Documents failing validation, written with the reason for correction. | XEDI to Blob |
How to connect Azure Blob Storage with EDI using XEDI
Two decisions shape this more than anything technical: which tier and how long the credential lives. The sequence below is what onboarding looks like from your side.
-
01
We agree the storage account, containers and paths that carry exchange traffic.
-
02
We settle how access is granted and, critically, how long it lasts.
-
03
We confirm the access tier applying to those containers.
-
04
We prove the flows, including retrieval behaviour if anything has been tiered down.
-
05
You get an exchange inside the Azure estate your organisation already governs.
Ready to connect Azure Blob Storage?
Talk through documents, mapping, testing and go-live with XEDI.
Everything about Azure Blob Storage EDI
Common requirements
- Storage account and containers
- Access method and credential lifetime
- Access tier on the exchange containers
- Naming and archiving conventions
- The trading partners the files relate to
What we need from you to build it
Only what we cannot decide for you. Partner requirements remain ours; tier and credential policy are your organisation's.
- Storage account and containers
- Which containers and paths carry exchange traffic, so access is scoped rather than account-wide.
- Access method and lifetime
- Whether a signature or a managed identity is granted, and when it expires, since an expiring credential stops an exchange silently.
- Access tier
- Which tier applies to the exchange containers, because an archived blob cannot be read until it has been rehydrated.
- Naming and archiving
- How blobs are named and where handled ones go, so nothing is collected a second time.
- The partners the files relate to
- Which relationships this covers. Their requirements are already held on our side.
Why suppliers choose XEDI for Azure Blob Storage
- Partners are commonly connected already, so tier and credential decisions are the substance of the work.
- The access tier on exchange containers is settled before a document becomes unretrievable during a dispute.
- Credential expiry is known and planned for rather than discovered when the exchange stops.
- Access is scoped to the containers involved, which is usually what your platform team requires anyway.
- Nothing about how your systems use Blob storage has to change.
- Partner requirements and validation stay with us regardless of what the storage estate does.
Can we use the archive tier for exchange containers?
It is not advisable. Blobs in archive cannot be read until rehydrated, which takes hours, and that is exactly the wrong characteristic for a document somebody needs during a query about what was sent.
Do you support managed identity rather than a shared access signature?
Where your policy allows it, yes, and it avoids the expiry problem entirely. Which route applies is usually decided by what your platform team permits.
What happens when our signature expires?
The expiry is agreed up front so it is planned rather than encountered. An exchange that stops because a credential lapsed is the most common avoidable failure on this route.
Plan your Azure Blob Storage EDI setup
Everything you need to scope, map and go live with Azure Blob Storage, in one place.