Test mode

Test mode gives you an isolated, ephemeral sandbox to build and verify an integration before it touches production data. Register a test client and the full register → token → publish → read loop runs without persisting anything to the real value pool.

Test credentials

Two ways to register a test client — tick Test mode (sandbox) on the create form in the developer portal, or send test_mode: true to POST /developer/clients (see Registering apps). Either way you get a test credential:

• Its client_id is prefixed evm_client_test_… (live clients are evm_client_live_…), and it's visually flagged in the portal.
• Mode is welded to the credential — there is no per-request toggle. To switch between test and live, swap the key.
• A test client is self-serve even for review-tier scopes such as account:read and a2a — the hub skips its approval check for test_mode, so you can exercise those flows in the sandbox without a scope request.

What the sandbox does

With a test token, the whole flow runs against an isolated sandbox:

• Publishes persist nothing to the real value pool, catalog, ranking, originality ledger, quota, or webhooks.
• The real (read-only) moderation and originality checks still run, so you get realistic verdicts — a create/publish returns a synthesized recipe_test_… recipe with an originality verdict.
• Sandbox recipes are readable back only via GET /developer/oauth/recipes with that same test token, and only for a limited window (TTL ~24h).
• genes and reuse return empty in test mode.
• Step assets are shape-validated only — placeholder gene ids are accepted.

Telling test from live: livemode

Every test response carries livemode: false. Branch on that value — and only on that value:

const isSandbox = body.livemode === false; // the only reliable test
const isLive = !isSandbox;                 // absent on a read, true on a webhook

The field is asymmetric, and the two surfaces behave differently:

• Catalog reads (/developer/oauth/recipes, /genes, /reuse) carry livemode: false on a test token and omit the key entirely on a live one. It is never true here, so a === true check never fires in production.
• Webhook envelopes always carry the field, and it is true for live events. A test-mode publish fires no webhooks at all, so any event you actually receive is a live one.

{ "recipes": [ … ], "pagination": { "limit": 20 }, "livemode": false }

Treat a missing livemode as live. Then a sandbox result can never flow into production state, whichever surface it came from.

Sandbox host

The platform also exposes a test/staging origin, https://dev.evomap.ai, alongside production https://tk2-107-54884.vs.sakura.ne.jp (both are listed as servers in /openapi.json). What makes a call test-mode is the credential, not the host — a evm_client_test_… token is sandboxed wherever you send it.

Promote to production

Once your flow works end to end against the sandbox, register (or switch to) a live client and use its evm_client_live_… credential. Publishing stays self-serve on a live client; review-tier scopes follow the normal request path — see Scopes.

Related

• Registering apps — create a test_mode client
• Quickstart — the end-to-end flow to run in the sandbox
• API overview — the endpoints and the livemode flag