← सभी गाइड पर लौटें

Debug API Errors: Fix 401, 402, 429, and 5xx

Failed API requests are easier to fix when you classify the HTTP status before changing code. A 401 usually points to authentication, a 402 to billing or account credit, a 429 to rate limits, and a 5xx response to a temporary provider or relay problem. Use the following workflow to isolate the cause quickly, whether you are calling an AI model directly or through a relay such as 59API.

1. Capture the complete request context

Start by recording the HTTP method, URL path, status code, response body, request ID, latency, model name, and retry count. Never log the full authorization header, API key, prompt contents, or personal data. Redact secrets and keep enough metadata to reproduce the failure.

Test outside your application with a minimal request. For an OpenAI-compatible client, verify that the base URL is set to https://api.59api.com, while preserving the SDK's expected path handling. A common mistake is duplicating a version path or pointing the client at a dashboard URL instead of the API base URL.

2. Fix 401 Unauthorized errors

Check that the authorization header is present and formatted correctly: Authorization: Bearer YOUR_API_KEY. Confirm that the key belongs to the environment currently running the request. Local development may use one key while a deployment uses an expired, missing, or incorrectly named secret.

Also inspect whitespace and configuration loading. An environment variable containing quotation marks, a trailing space, or an empty value can produce a valid-looking but unusable header. Rotate the key if it may have been exposed, then restart the process so it reloads the updated secret. If the key is valid but the request still fails, verify that the selected model is available to your account and that the request is being sent to the intended base URL.

3. Resolve 402 Payment Required errors

A 402 generally means the service cannot authorize usage because the account has insufficient balance, an inactive payment setup, or a billing restriction. Check your account balance, payment status, usage limits, and whether a spending cap was reached. Do not respond by blindly retrying: the same request will continue to fail until the account state changes.

For predictable costs, record token usage and set application-level budgets. 59API is useful for teams that want pay-as-you-go access to Claude models, including Opus, Sonnet, Haiku, and Fable, as well as GPT models through an OpenAI-compatible interface. Its low-cost relay model and referral rebate can help reduce operating costs, while native official-quality models avoid an unexpected quality downgrade. After adding credit or correcting billing, retry one small request before restoring normal traffic.

4. Handle 429 Too Many Requests

A 429 indicates that your request rate, concurrency, or usage volume exceeded a limit. Read the Retry-After header when present. Otherwise, use exponential backoff with jitter, such as delays of 1, 2, 4, and 8 seconds plus a small random value. Cap the delay and the total number of attempts.

Reduce concurrency with a queue or semaphore, and avoid retrying every request at once after an outage. Cache stable responses where appropriate, shorten unnecessary prompts, and apply separate limits for interactive traffic and background jobs. Retry only transient failures and preserve an idempotency strategy for operations that could be submitted twice.

5. Investigate 5xx responses

5xx errors usually indicate a temporary failure in the provider, relay, gateway, or upstream model service. First determine whether the error is consistent across models, payload sizes, and regions. A 500 may expose a malformed request that the server handled poorly, while a 502 or 503 often suggests an upstream or availability issue. A 504 commonly means the request timed out.

Retry safe requests with capped exponential backoff, then use a circuit breaker so an unhealthy dependency does not consume all your worker capacity. Add a request timeout, monitor latency and error rate, and preserve the returned request ID for support. If only one model or unusually large prompt fails, validate the payload and reduce its size before escalating.

6. Add a repeatable diagnosis checklist

• Confirm the base URL, endpoint path, HTTP method, and content type.
• Validate the API key and account balance without exposing secrets.
• Check response headers for request IDs, rate-limit data, and Retry-After.
• Retry only transient 429 and 5xx failures with bounded backoff.
• Test a minimal payload and one known-available model.
• Alert on recurring failures instead of hiding them with infinite retries.

If you need inexpensive access while debugging an OpenAI SDK, Claude Code, or Codex integration, you can sign up for 59API and test the same minimal request against its compatible API base URL before moving production traffic.

मूल्य · दस्तावेज़