Get a request back on track.

Check service status, then separate account access, API authentication, model discovery, inference and payment problems. A model appearing in the catalogue does not establish live availability: GET /v1/models lists connected deployments.

A 503 service_unavailable means the required service cannot accept the request. Check service status and the API reference before retrying; repeated requests cannot enable an unavailable service. For a dedicated GPU, wait for confirmed provisioning. For payments, follow the order’s instructions and recorded verification status; refreshing an order does not add credit.

Record the HTTP status and the error’s code and message. Check the configured API base URL, exact model ID and client version before changing application logic.

• 401: check the Bearer header and whether the key was revoked. Keep the full key out of logs.
• 403: choose a model permitted by the key’s allowlist.
• 400 or 413: check JSON, required fields, output limit and the combined input/output context budget.
• 402: check whether the account has a qualifying confirmed top-up of at least USD 100, then check available credit and the selected key’s budget; qualified accounts do not need to maintain a USD 100 balance.
• 429: follow a Retry-After header if provided, use bounded retries and check the applicable service limits; there is no daily free-trial allowance.
• 502 or 503: check availability and the error message before a bounded retry.

The error guide and limits explain the recovery paths. A new request can create new work; do not assume client retries are deduplicated.

A closed browser tab, timeout or broken stream does not prove that generation stopped. Save any response identifier and the final usage frame if received. The final usage frame may arrive after the choice’s finish_reason; a network chunk is not necessarily a complete event.

A 409 pending_reconciliation, or an upstream error after dispatch, can leave credit reserved until authoritative usage is available. Avoid sending duplicate requests to clear the hold. Compare the UTC time, model and key name with console usage, and retain the request details for reconciliation. Clearance times are not guaranteed.

For a payment issue, record the order reference, asset, network, amount and visible status. Never send another payment merely because the first is pending. Wallet withdrawals are currently unavailable. Cancelling a paid GPU order before activation returns its payment to the WeightsAPI account balance; it does not transfer funds to a wallet.

A useful report includes the operation, UTC timestamp, endpoint path, model ID, SDK or integration and version, streaming setting, output-token limit, status/error, expected result and actual result. Include a response or transaction reference only if available; the gateway does not currently expose a support ID on every error.

Add the smallest synthetic example that reproduces the problem. Replace real conversations, customer records and private documents with invented text. Include relevant retry counts and whether the issue repeats across requests. Screenshots should show the error and context after removing credentials, balances or identifiers you do not intend to share.

For a dedicated GPU order, include the order reference, configuration and visible payment or provisioning status. A pending order is not an active machine.

Never include an API secret, Authorization header, session cookie, private wallet key, recovery phrase or full environment file. A key name or deliberately shortened prefix is enough to distinguish applications. Public transaction references may still connect activity to a wallet; share only what the investigation needs.

If a key was exposed, create a replacement, update the application and revoke the old key. Revocation blocks new admissions; previously admitted requests settle normally. See authentication for key handling.

Copy and review your report, then keep it with the relevant request or order reference. Copying does not submit a ticket. Official support contacts and service hours are not published; use only a confirmed channel to share a report.

Response targets, escalation contacts and service credits have not been established. Keep credentials and sensitive customer content out of your report.