# Errors and troubleshooting

Availability: Release contract.
Last reviewed: 2026-08-28.

Classify the failure before choosing a recovery action. Never use a retry as a substitute for understanding an uncertain result.

## Authentication problems

Check that the release is available, the request uses the documented header and the key remains active. A replacement invalidates the prior key immediately. Keep secrets out of screenshots, support messages and debug logs.

A denied resource can mean insufficient authority, not a missing object. Do not probe neighboring identifiers to find an accessible account.

## Request and availability problems

If a verified signup response is lost, resume its existing preparation; do not start another account or application. A key may already exist even when its one-time secret was not received. Inspect safe metadata and explicitly replace it if necessary. A consumed code cannot authenticate another session: request a fresh code when no valid developer session remains.

For sensitive administration, a recent-proof prompt does not mean the whole session expired. Routine browsing remains signed in within the seven-day absolute and twelve-hour idle limits. Reverify only the intended sensitive action; failed or cancelled step-up must not silently execute it.

Malformed inputs, operational rate limits, missing prerequisites and unavailable capabilities need different responses. A planned API cannot be made available by changing parameters, adding credits or bypassing the developer interface.

For a throttle, follow returned timing. For a temporary network failure, retain the request context and inspect safe status before creating anything again.

## Business-operation conflicts

Future idempotency conflicts must distinguish the same intent from a changed payload. Keep immutable operation identity and scope. Partial results are not automatically failures; an uncertain provider attempt must not be replayed through “retry all”.

## Ask for help safely

Provide the article, safe request/operation reference, time, HTTP status and a concise symptom. Omit API keys, verification codes, cookies, payment details and raw private evidence. Support contact does not authorize repair, provider work or financial changes.