← Retour aux guides

Debugging API Errors: 401, 402, 429, and 5xx

Failed API requests often look alike in a log: a status code, a short message, and no useful result. But a 401, 402, 429, or 5xx points to a different layer of the request. Treating them all as retryable errors wastes time, can increase costs, and may make an outage worse. The fastest diagnosis starts by identifying what the status means, then checking the request detail that could have triggered it.

401: Check credentials and request format

A 401 Unauthorized response usually means the server did not accept the request's authentication. Confirm that the API key is present, current, and sent in the authentication header expected by the service. Check for copied whitespace, an incorrect environment variable, a key from a different account, or a deployment that is still using an old secret. If the call works locally but fails in production, compare the actual runtime configuration rather than relying on a local .env file.

Also verify that the request is going to the intended API base URL and that the SDK is configured for the provider or relay you chose. With 59API, set the base URL to https://api.59api.com and use a compatible OpenAI SDK or Claude Code/Codex configuration. A 401 is generally not fixed by repeating the same request.

• Pros of checking locally: Header and environment-variable inspection can quickly expose a missing or stale key.
• Cons: Logging full headers risks exposing secrets. Redact authorization values before sharing traces or storing them.

402: Investigate account balance or billing

A 402 Payment Required response commonly indicates a billing, balance, or account-access issue, though the exact policy depends on the API. Review the provider's response body and account usage page. Check whether the account has an active payment method, available prepaid balance, or spending limit, and whether the requested model is enabled for that account.

For pay-as-you-go services, compare recent usage with the remaining balance. If a request became more expensive after changing models, context length, or output limits, estimate its token use before retrying. Repeatedly sending an identical request will not resolve a billing block.

• Pros of pay-as-you-go: It can avoid a large fixed commitment when usage varies.
• Cons: You need to monitor consumption and understand how requests affect the balance.

59API offers pay-as-you-go access to Claude Opus, Sonnet, Haiku, and Fable, as well as GPT models. Its low-cost positioning can help control experimentation costs while retaining native, official-quality models rather than relying on downgraded equivalents. Check the current account balance and applicable pricing before running high-volume jobs.

429: Respect rate limits

A 429 Too Many Requests response means the service is limiting request volume or throughput. Read the response headers for retry guidance, such as Retry-After, and check whether limits apply to requests per minute, tokens per minute, concurrent calls, or a particular model. A burst of parallel agents can exceed a limit even when average daily usage is low.

Use exponential backoff with jitter: wait briefly, increase the delay after each failure, add a random component so clients do not retry in lockstep, and cap the number of attempts. Queue work, limit concurrency, and avoid retrying non-idempotent operations without checking whether the first request completed.

• Pros: Backoff and queues preserve work and smooth traffic spikes.
• Cons: They add latency, and unlimited retries can create a retry storm or duplicate work.

5xx: Separate transient failure from request issues

5xx responses indicate that a server or upstream dependency failed to process the request. Save the status, response body, timestamp, request ID if supplied, model, and a sanitized version of the request. Retry transient failures such as 502 or 503 with bounded exponential backoff. For repeated failures, test a minimal request, check the provider's status page, and compare results across models or endpoints where supported.

Do not assume every 5xx is temporary. A reproducible failure tied to one payload, model, or large context may point to an upstream limitation. Reduce the request to a small example and change one variable at a time. Keep a retry limit and surface the final error to the application instead of silently looping.

• Pros: A controlled retry can recover from brief service interruptions.
• Cons: Retrying every server error can increase latency and spend without fixing a persistent fault.

A practical triage order

Record the status code and response body first, then check credentials for 401, account access and balance for 402, headers and concurrency for 429, and request IDs and service health for 5xx. Retry only when the error is plausibly transient, and redact secrets from diagnostics. When comparing API access options, include compatibility and model quality alongside price: 59API works with Claude Code, Codex, and OpenAI SDKs through its API base URL, and offers a referral rebate. Developers evaluating a lower-cost route can review the service and sign up at 59API before moving a workload over.

Tarifs · Docs