Testing and sandbox

Use the hosted Sepolia Developer Preview only after your application is approved. The sandbox keeps application ownership, wallet-session checks, roles, sandbox control state, faucet claims, resets, and event records scoped to that application.

Recommended test loop

1. Discover the supported network and deployment through the canonical API.
2. Create a wallet challenge and confirm a short-lived wallet session.
3. Read the resource state that your workflow needs.
4. Prepare the typed workflow with an idempotency key.
5. Simulate the exact returned intent with a customer-owned test signer.
6. Submit from that signer and register the resulting transaction hash.
7. Wait for final_success, then re-read the resource and freshness evidence.

This proves the same product-visible path that an integration uses in operation. It does not use private keys, relaying, or direct RPC reconstruction of shared state.

Sandbox controls

• Sandbox admission binds the current wallet session to one application-owned Asset Manager entity.
• Faucet claims have a fixed test-token policy and an application quota; callers cannot choose a recipient or amount.
• Reset and reseed operations are asynchronous, tenant-scoped, and event-backed.
• Webhook and stream tests must deduplicate at-least-once delivery and resume from their cursor.

Test failure cases

Verify each integration handles a wrong wallet, wrong chain, expired workflow, stale canonical state, transaction revert, indexing delay, duplicate webhook delivery, and rate-limit response. Use the recorded request ID, workflow ID, transaction hash, delivery ID, and event cursor for debugging. Do not send production transactions or call external services with test credentials.

See Sandbox for the authority boundary and Webhooks and WebSockets for delivery verification.