A failed API request is easier to fix when you reduce it to one small, observable test. Start with the HTTP status and response body. Avoid changing the host, key, model, and request parameters all at once: each change removes information about the original failure.
Check the destination and credential
Inference requests belong at https://api.gatepx.ai/v1. For chat completions, the full URL is https://api.gatepx.ai/v1/chat/completions. Check for a duplicated /v1, an old environment override, or a request sent to the website or documentation host.
Use a Gatepx API key in Authorization: Bearer .... Verify that the server actually received the intended environment variable without printing its value. Your browser sign-in session, website password, and upstream provider key are separate credentials.
Check what your model and key allow
List models with /v1/models using the same key as the failing request. Select an enabled ID exactly as returned, then send a small text request if the model supports chat. Check key expiry, restrictions, and your account balance or quota in the dashboard.
If a small request succeeds but the full request fails, add the original parameters back gradually. Look at input size, output limits, tools, media, and structured-output settings. A supported base API does not establish support for every parameter on every model.
Use the status as a starting point
- 400: inspect the body, model parameters, and request format. Repeating an invalid request unchanged usually does not resolve it.
- 401 or 403: check the credential, expiry, permissions, account restrictions, and response body. An HTML response can indicate an intermediary rather than the expected JSON API response.
- 429: slow down and inspect the error for rate or quota limits. Account, key, server, and upstream limits may differ.
- 5xx: retain the response details and request ID. Retry only when the workload can tolerate a repeated attempt.
These are diagnostic starting points, not a promise that every upstream provider uses identical error fields. Read the actual message alongside the status.
Avoid multiplying retries
Check both the SDK retry policy and any retry loop in your application. Two independent layers can produce more attempts than you intended. Use a bounded policy for transient failures, honor Retry-After when present, and avoid endless retries for invalid requests or exhausted quota.
If a stream fails after producing text, treat that text as partial. A new request is a new generation and may create another charge. Do not merge a retried result into the previous partial output without telling the reader.
Send a useful support report
- Record the time, API host, endpoint, model ID, HTTP status, and a redacted error message.
- Include the
X-Oneapi-Request-Idresponse header when present and the corresponding dashboard usage record. - Provide a minimal reproduction with placeholder credentials. Remove API keys, session cookies, personal data, and sensitive prompt text.
Contact [email protected] with those details. The errors documentation, rate-limit reference, and streaming guide provide the next checks for the relevant failure path.