Test in the sandbox
Same API, sandbox keys, nothing settles — and how to force every verdict on purpose.
The sandbox is the same API on different keys: sk_sandbox_ and ak_sandbox_ instead of the live prefixes, issued together at onboarding. It evaluates against your draft policies, meters, logs, signs — and settles nothing. This page collects what is otherwise spread across the reference, plus the part everyone actually wants: how to get each verdict on demand.
What is real and what is not
Real: evaluation, verdicts, reviews, the log, webhooks, escrow objects and their transitions. Signed verdicts verify against the same public key set at verdicts.saifuro.com.
Not real: settlement. No provider is called, no funds move, no fees accrue.
Distinguishable: sandbox verdicts carry a kid starting with sandbox-. A counterparty that delivers real goods should reject those — and your own test consumers should require them, so a production token in a test path is just as loud.
Force every verdict
Verdicts come from policy, so you produce each one by shaping the mandate and the request — no magic values, the same mechanics as production. Each row below assumes a fresh agent holding a single mandate: the engine weighs every mandate an agent has ever held, so once you revoke or expire one, reuse the same agent and you keep getting deny_revoked or deny_expired. One agent per row keeps the results clean.
| You want | Do this |
|---|---|
allow | Request inside the mandate: amount under per_transaction, category on the list |
review | Amount between review_above and per_transaction |
deny_limit | Amount over per_transaction, or enough requests to pass per_month |
deny_category | A category the mandate does not list |
deny_velocity | Repeat requests until a frequency rule in your draft policy fires |
deny_expired | A mandate whose expires date has passed |
deny_revoked | Revoke the mandate, then request again |
deny_no_mandate | A fresh agent with no mandate at all |
The velocity row needs no setup either: the draft sandbox policy ships with one frequency rule, and more than ten requests from one agent inside a minute returns deny_velocity.
The first authorization guide walks allow, deny_limit, review and deny_revoked end to end, and points at deny_category along the way.
Replay your own traffic
An organization key may create authorizations on behalf of any agent, which is how you replay a slice of production history against draft policies before anything enforces:
curl -X POST https://api.saifuro.com/v1/authorizations \
-H "Authorization: Bearer sk_sandbox_..." \
-d '{ "agent": "agt_procurement_01", "amount": 340.00, "currency": "USD", "recipient": "vendor:acme_saas", "category": "saas" }'Feed it yesterday's spend, read the verdicts, adjust the draft, repeat. This is a smaller, self-serve version of what observe mode does against live traffic for thirty days.
Escrows simulate the chain
Sandbox escrows walk the real states without a real chain. The contract address is a placeholder that exists on no chain; funding happens on its own about fifteen seconds after creation, and escrow.funded fires. Attestation moves the deal through delivered to released at once, and a deadline that passes unmet refunds. Nothing settles.
What the sandbox cannot tell you
Two things, and pretending otherwise would bite later. Latency: sandbox numbers reflect nothing about your production network path, which is why p50 and p99 are measured in observe mode on your own traffic. And preventive enforcement: whether an agent truly has no second route to a provider is a property of your egress, checked during scoping — not something a sandbox request can prove.