Sume API 401 on the dev host: keys only work on their own host

A Sume API key works only on the host it was created for. A production key sent to api.dev.sume.com returns 401, and a dev key sent to api.sume.com does the same. Check which dashboard created the key before you debug anything else.

The failure looks like a revoked key, which sends people into rotating credentials that were fine. The cause is simply a mismatch between the key and the base URL.

Rotating a key that was fine also leaves you with two keys to track and a deploy to redo, which is a poor trade for a typo in an environment variable.

The symptom and the one-line check

Every call returns 401 even though the key is correct and was pasted without whitespace. Print the base URL your client is using, and compare it to the dashboard where you minted the key. The Call a Format page states that the other host answers 401.

The production base is https://api.sume.com, and the key is read from the SUME_API_KEY environment variable in every example we publish. If you run two environments, give them different variable names in your own code, for example one for each host, so a copy and paste cannot swap them.

A useful smoke test is a read call you already know should succeed, such as listing the runs of a Format you own. If the read gets 401, the problem is the key and host pair; if it succeeds and the create gets 403, the problem is scope or key type.

Other 401 and 403 lookalikes

Not every auth failure is a host mismatch. A 403 with insufficient_scope means the key lacks formats:read or formats:write; keys minted before the Formats release do not have them, so mint a new key. A service-account key cannot create Format runs at all and returns 403 with details.reason set to service_account_format_runs_unsupported. A team Format called with a personal key returns 403 workspace_key_required.

Read the status code first, then the error code in the body. The table separates them.

Keep staging from spending real money

Wallets and keys are separate per host, so a test on the dev host does not draw down your production wallet. That is a reason to keep a staging key rather than testing with the production one. Whatever you do, set generation_spend_cap_usd on test runs; the cap is the guardrail that exists on every host.

Put the base URL in configuration and fail at startup if it does not match the environment name. A guard that refuses to boot when ENV is production and the host contains dev is five lines and prevents the whole class of confusion.

Document the pairing in your README as a table of environment, base URL, and variable name. New teammates will hit this within their first hour.