Isolation, in four independent layers
No single misconfiguration collapses the separation between your trading partners. Each layer would have to fail on its own.
Jailed mailboxes
Each dealer is locked to their own directory and can see nothing above it — not the customer root, not a sibling dealer. Your own account sees every one of your dealers and no other company's.
Asymmetric permissions
Permissions are granted per folder, and deliberately not symmetrical. A dealer can read what you send but cannot delete it, and cannot write into the outbound folder at all — so a dealer can neither destroy a document you sent nor forge one that appears to come from you.
Database-enforced tenancy
Separation is enforced by the database itself through row-level security, not by application code remembering to filter. A query that forgets a tenant returns nothing rather than someone else's data.
Hardened naming
Every account and folder name is validated before use: a restricted character set, no traversal sequences, no leading dashes, length-bounded, case-sensitive. Paths are assembled from already-validated parts rather than normalised after the fact.
Onboarding a partner
Adding a dealer is one form. Behind it, a sequence that either completes or unwinds itself.
Provisioning that cleans up after itself
Creating a mailbox is several steps — the account, its jail, its folders, its permissions, its address restrictions. If any step fails, the earlier ones are reversed. You never end up with a half-built partner that looks fine on screen.
Per-partner address restrictions
A mailbox can be restricted to the network addresses you nominate, so a leaked credential is not enough on its own to connect.
Drift detection
The system compares what it believes exists against what the file server actually has, reports any divergence, and can safely roll forward. It reports rather than deletes — the one repair that cannot be undone is never automatic.
Credential management
Mailbox credentials are issued and rotated as a first-class operation, by password or SSH key, without disturbing anything else about the partner.
The document lifecycle
Proven end to end with a real bidirectional exchange: a business document out, a functional acknowledgement back, correlated automatically.
| What happens | What the system does |
|---|---|
| You send a document | It is recorded, checksummed, and its EDI envelope read. The upload is written to the audit trail with the real source address. |
| Your dealer collects it | The document is marked collected and timestamped. A second audit entry is written. |
| Your dealer acknowledges | The acknowledgement is matched to the original by its control number, in the opposite direction, in the same environment. The original is marked acknowledged. |
| You collect the acknowledgement | It is archived verbatim — the exact bytes your partner sent, kept as evidence. |
Files on disk are transient; the database is the archive. A completed document is removed from the mailbox once it has been acknowledged — its full history, timestamps and acknowledgement stay permanently in the record.
An unmatched acknowledgement is not an error. If a partner acknowledges something the system has no live original for, the control number is kept, the anomaly is flagged on the record, and processing continues.
Visibility and evidence
The question that matters in a dispute is "what actually happened, and when" — so the record is built to answer it.
Append-only audit trail
Every transfer and every administrative action is recorded with the real actor and the real source address. The trail cannot be edited or deleted — that is enforced by database permissions, not by policy.
Envelope inspection
Each file's EDI envelope is read on arrival: document type, sender and receiver, control numbers, and whether the envelope is well formed — so a malformed file is identified when it lands rather than when someone complains.
Operations dashboard
Staff see volumes, activity per customer, and documents that have gone unclaimed — the operational view, across every tenant.
Customer self-service
Your own people sign in to see their dealers, their document history and their notification settings, and to add a dealer — without going through us.
It tells you when something stalls
The failure that costs money in EDI is not a loud error. It is a document nobody collected and nobody noticed.
Stall detection
Documents sitting uncollected past a threshold raise a reminder, automatically, on a schedule — so an unattended partner surfaces on its own.
Email delivery
Notifications are delivered through Microsoft 365, addressed per partner. Each dealer can have their own recipient, or fall back to a central operations address.
Webhook delivery
Routing a partner's notifications to a webhook rather than an inbox. The preference can be set today; delivery to a webhook endpoint is not yet built, and a partner set this way is logged rather than silently dropped.
Retention
Per-customer retention policies expire aged files and acknowledgements on a schedule, so the estate does not grow without bound.
How partners connect
Standard SFTP — a password or an SSH key, optionally restricted to nominated network addresses. Partners collect from an outbound folder and drop acknowledgements into an inbound one.
Nothing proprietary is required at the dealer's end. A partner with a full EDI system automates against it; a partner with nothing but a free SFTP client does exactly the same job by hand. Both are ordinary trading partners as far as the hub is concerned.
What this product deliberately does not do
Stated plainly, because the wrong answer here is expensive later.
- It does not convert or map EDI to your ERP.
- This is a mailbox and a document hub. It moves, records and acknowledges files. Mapping a purchase order into your ERP's format is permanently out of scope — not deferred work, and not on a roadmap.
- It does not fully parse document contents.
- It reads the envelope — types, partners, control numbers, structural validity — and the acknowledgement details it needs to correlate. It does not interpret the line items inside a document.
- There is no dealer-facing portal.
- Your dealers interact through SFTP and their own systems. A web portal for them is not built.
The Customer Application is the other half of this story — it is what produces the documents this hub carries. See what it does →