Written for the Director of Restaurant Technology — the seat that owns the handhelds, the store systems, and every one-off supplier feed the last three rollouts left behind.

There was, for most of a decade, one developer-EDI platform your engineers actually admired. Its public X12 reference was the page everyone kept in a tab. Its JSON-first translation APIs were the standing rebuke to the managed-EDI networks. If you were ever going to modernize the document layer under your supplier feeds, it was the obvious place to start.

It is now a healthcare clearinghouse. That is not an insult; it is their own copy.

The public trail, dated

Every fact below is from the vendor's own pages, with dates, so you can check each one without us.

  • May 6, 2024 — Stedi announces "Stedi Healthcare: the only API-first clearinghouse for health tech companies." The post does not mention the general-EDI business.
  • September 2025 — Series B: $70M, co-led by Stripe and Addition, "to build the only AI-enabled clearinghouse."
  • March 2026 — Series C: $50M led by Addition, $142M raised in total, positioning verbatim: "the only healthcare clearinghouse for agentic RCM."
  • July 2026 — the changelog runs one to two shipped entries per day, essentially all of them healthcare claim edits. The homepage tagline is "The only programmable healthcare clearinghouse." Retail and logistics use cases no longer appear on the product pages.

Two things about that trail deserve respect. First, it is a magnificent business — paying customers up 6x year over year, billed transactions up 7x, more than a billion claims and eligibility transactions annually, by their own Series C post. Second, the pivot was never announced as an exit from supply chain. There is no sunset notice. The machinery stayed up. The market attention simply moved, completely, to a different industry.

What stayed up, and what quietly has no owner

The X12 reference is still live, still free, and still excellent. We verified it directly on 2026-07-31: the 850, 856, 810, 846, 940, 945, 214 and 997 pages all answer, across releases, and the old deep links still redirect home. We link that reference wherever X12 segment detail is needed — Stedi's 856 reference, with credit — and we never reproduce it, because X12's copyright bars republication and because linking the canonical reference is simply the honest move.

What has no owner is the thing the reference was supposed to serve: the join between trading documents and custody events.

Here is our search result, stated as a search result and not as market fact. On 2026-07-31 we swept the remaining developer-EDI field — Orderful, Zenbridge, Cleo, SPS Commerce, TrueCommerce — against their own developer portals. Every one of them rebranded around AI within the last twelve months. Not one of them ships an EPCIS product. The GS1 surface across all five stops at GS1-128 label generation and GDSN content sync. A document goes in; JSON comes out; and the question a regulator, an auditor, or your own trace tooling actually asks — which physical events does this purchase order govern, and does what was shipped match what was seen — is answered by nobody.

Why this lands on your desk specifically

You are the seat scarred by per-supplier one-off feeds. Every rollout you have inherited inherits every supplier's format forever: EPCIS 1.1 XML from the vendor who integrated in 2016, CSV from the produce distributor, bespoke JSON from the new protein supplier's SaaS. The developer-EDI field's exit makes that tax permanent by default, because the vendors still standing sell either a managed network (join ours, forever) or a translation layer that stops at JSON and never touches your event record.

And the onboarding sweep the tax funds is itself delegable — supplier onboarding is an agent's job — but only once the formats land somewhere that joins them to events.

The structural point is that the join now has to live with whoever owns the event record — because the standard put it there. CBV 2.0 §7.3 defines po and desadv as core business-transaction types (the desadv definition itself notes it is "also called an 'Advanced Shipment Notice'"), and CBV 2.0 §8.5 places bizTransactionList on every EPCIS event type. The vocabulary for citing your paperwork inside your trace has been core spec since 2022 — the spec-level walkthrough is po and desadv are core CBV. The document side of that same join is transactions.dev, the family's business-transaction door; the standing executive read is ASN and PO context in traces.

visibility.cloud takes documents in on that basis: supplier feeds arrive in whatever the supplier has, compile to business-transaction references on conformant events, and the trace cites the PO and the ASN the way the spec always intended. One record, with your paperwork in the why dimension of it.

The test to run on any "modern EDI" pitch

You will hear the field's remaining vendors describe themselves as AI-native, agentic, and orchestration-first. The test costs one sentence: "Show me the document cited inside a trace." Not a JSON rendering of an 856 — an event record where the receiving event carries the ASN reference, the purchase-order reference, and the attested observer who received against them, in core-spec fields a conformant consumer already understands.

If the answer is a mapping screen, you are looking at the translation layer the field already built ten years ago. The join is the part nobody stayed to finish.

If your suppliers' feeds are the tax you pay on every rollout, start the interview — it asks about your receiving reality, not your budget, and it ends with exactly one promise about contact.