Troubleshooting

Debug Supado requests from the outside in: client configuration, HTTP request, Supado log, upstream behavior, then application retry logic.

Before you start

Prepare a safe minimal request:

curl https://supado.com/v1/chat/completions \
  -H "Authorization: Bearer $SUPADO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Reply with ok."}]}'

Use a test prompt that does not include customer data. Do not paste real API keys into support channels.

Troubleshooting

1. Confirm the request reaches Supado

• The base URL is https://supado.com/v1.
• The endpoint path starts with /chat/completions or another documented public endpoint.
• The request includes Authorization: Bearer ....
• Your app is not accidentally using an old direct-provider client.

2. Match the error to the first check

Symptom	First check
401	API key exists, is copied correctly, and is loaded by the running process.
403	Account or key permission for the selected model or endpoint.
404	Endpoint path and model name.
429	Quota, balance, rate limit, concurrency, or retry loop.
5xx	Retry with backoff and collect request details.
No Supado log	Wrong base URL, network block, or request failed before reaching Supado.

3. Reduce the request

Remove optional fields until the request is minimal:

{
  "model": "gpt-4o-mini",
  "messages": [
    { "role": "user", "content": "Reply with ok." }
  ]
}

Add optional fields back one at a time. This identifies whether the failure is caused by the model, endpoint, auth, or a specific parameter.

Support handoff

Before asking for support, collect:

• request time with timezone
• endpoint path
• model name
• status code
• request id if visible in Supado
• whether the request appears in the Supado console
• sanitized response body
• whether the same request works with curl

Do not include API keys, full prompts, customer data, or screenshots that expose secrets.

Frequent causes

Cause	Why it matters
Starting with production traffic	Too many variables change at once. Reproduce with one minimal request.
Reporting only “it failed”	Status code, endpoint, model, and request time are needed to trace it.
Retrying every error	Retrying 401 or invalid 400 requests only adds noise.
Ignoring local deploy state	The environment variable may be fixed locally but missing in production.
Proxy buffering	Streaming may look like a delayed non-streaming response.

If a minimal curl request works but your application fails, the issue is usually client configuration, request construction, or deployment secrets.