How it's captured.
The item, the party, the place, the time and the step all arrive through an interface, and the interface is the standard's, not a vendor's. visibility.cloud translates a decade of legacy formats into EPCIS 2.0 today, and will capture and query over the standard's own REST API, opening the same door to agents as to people. That door answers at api.epcis.dev to a capture key today; issuing those keys is not open yet.
The API.
Capture and query over the EPCIS 2.0 REST interface, implemented against GS1's official OpenAPI description and pinned by digest. Every capture is validated against the official JSON schema before it is accepted; a capture that does not validate is refused, in RFC 7807 problem+json, carrying the standard's own exception types. More on the APIs →
The legacy.
Ten years of vendor XML and EDI do not vanish because a standard arrived. The spine translates EPCIS 1.1, 1.2 and 2.0 XML into 2.0 JSON-LD with a round-trip fidelity report per job, and the EDI those systems still speak is what it is built to interoperate with rather than ignore. More on EDI →
A door for agents.
The same interface, the same key, over MCP, so a partner's logistics agent can capture and query without a human copying values between two systems. The door for agents is the same door as the one for people. The developer side of the whole spine is epcis.dev.
How, in detail.
The two method pages the interfaces break down into.
The standard gives you this dimension. Here is what it still can't tell you.
EPCIS 2.0 §7.2.2 defines five event dimensions — and no performer is among them. The record can say a company did a process. It cannot say who observed the event. That answer has its own door.
how: answered — POST /capture → validated → hashed → appended who: (no field exists in the standard)
See your first trace.
Your capture workspace is provisioned from the seat list — we write when your seat is ready.