APIs.
Events reach the spine through the standard's own interface, not a vendor's. visibility.cloud will capture and query over the EPCIS 2.0 REST API, implemented against GS1's official OpenAPI description and pinned by digest, and no capture will be accepted before it validates. The engine that does it is built, its tests pass, and it answers at api.epcis.dev to a capture key — issuing those keys is not open yet. The validation door is already open at epcis.dev/validate.
A capture that does not validate against the official GS1 EPCIS 2.0 JSON schema is refused, in RFC 7807 problem+json, carrying the standard's own exception types rather than a vendor error string. recordTime, the capturing party and the attestation grade are stamped at the gateway; whatever the sender wrote in those fields is stripped.
The same interface, the same key, is exposed to agents over MCP, so a partner's logistics agent can capture and query without a human copying values between two systems. The developer side of the same spine, with the capture interface, the schema validation, the event hash and the error bodies, is epcis.dev — where the translate, validate and hash doors of the same spine answer over HTTPS today, and the capture and query interfaces answer at api.epcis.dev to a capture key.
A refusal, in the standard’s own words: what the door answers when a capture does not validate.
HTTP/1.1 400 Bad Request content-type: application/problem+json { "type": "epcisException:ValidationException", "title": "EPCIS document failed validation against the official schema", "status": 400, "detail": "(the standard’s own exception type — not a vendor error string)" }
See your first trace.
Capture workspaces are provisioned from the seat list — we write when your seat is ready.