Hosted Agent Sandbox

The hosted Sandbox lets a company Agent exercise the stable supply-y/1.0 API contract without a customer account or production credentials. It uses public fictional fixtures, verifies signatures and lifecycle bindings, stores only the test exchange state, and deletes the complete namespace after 60 minutes.

Open the interactive Sandbox.

What runs for real

1. The Sandbox creates an isolated Bearer token and Redis namespace.
2. Sender and recipient Agents register their public signing and encryption keys.
3. The sender submits a signed Policy Receipt for the exact Package digest and recipients.
4. The Sandbox validates the receipt contract, verifies its ES256 signature and records whether Package submission is eligible.
5. The sender submits a flattened JWS containing readable authenticated metadata and JWE ciphertext.
6. The Sandbox verifies the outer signature, canonical envelope, authenticated metadata, two-recipient JWE shape, eligible Policy Receipt and idempotency key. It never decrypts the business object.
7. The recipient submits a signed lifecycle receipt.
8. The Sandbox returns ordered notifications, Package evidence and a thread hash-chain head.

Start a session

curl -X POST https://supply-y.net/sandbox/api/sessions

The response contains:

• access_token: a one-time-visible Bearer token for this test namespace;
• api_base_url: https://supply-y.net/sandbox/api/v1;
• fixture_url: a fresh signed material-risk fixture bound to the session;
• expires_at: the automatic deletion time;
• request_limit: the session request allowance.

Use the token only in an Authorization: Bearer ... header. Every Protocol mutation also requires Idempotency-Key.

Agent execution order

After creating a session, fetch its fresh fixture from GET /sandbox/api/fixture. Execute the supplied objects and idempotency keys in this order:

Step	Operation	Expected result
1	POST /v1/agents/register for sender	201 AgentResource
2	POST /v1/agents/register for recipient	201 AgentResource
3	POST /v1/policy-receipts	201, signature_status=verified, package_authorization=eligible
4	POST /v1/packages	202 PackageResource, state=accepted
5	POST /v1/packages/{package_id}/receipts	201 ReceiptResource, state=received
6	GET /v1/audit/packages/{package_id}	signed Package evidence and ordered events
7	GET /v1/audit/threads/{thread_id}	ordered events and chain_head

The same idempotency key returns the original response with Idempotency-Replayed: true. A different key cannot create a duplicate Agent, key or Package ID.

Data and storage boundary

• Hosted sessions use the Supply-Y Upstash Redis resource in the San Francisco region.
• Redis stores the session, public keys, signed Policy Receipt, encrypted Package bytes, lifecycle receipts, notifications and audit metadata.
• The Sandbox token is stored only as a SHA-256 digest.
• The fixture contains public test keys and fictional automotive supply-chain data.
• Session keys expire after 60 minutes. This is not an approved location for customer data.
• Local development uses an in-memory fallback when Redis credentials are absent.

What this proves

A successful run proves that the Agent can call the published request sequence, satisfy the current API schemas, present verifiable test signatures, preserve Package bindings, handle idempotency and read audit evidence.

It does not certify a company Agent, customer KMS or HSM, production identity, live Catena-X connector, business truth, operational SLA or production data handling. Those remain managed-pilot and certification gates.