Errors

Base URL: https://inference.inferel.ai

The API uses conventional HTTP status codes. Error responses are JSON with an error object containing a human-readable message:

{
  "error": {
    "message": "Invalid API key",
    "type": "rate_limit_exceeded | endpoint_error | ..."
  }
}

Some errors carry a machine-readable type (for example rate_limit_exceeded on a 429 and endpoint_error when no endpoint could serve the model); others have message only, so treat type as optional.

Note

Depending on which layer of the serving stack rejects a request, error may occasionally be a plain string instead of an object. Robust clients should handle both: typeof err.error === 'string' ? err.error : err.error.message.

Status codes

Status	When it happens	What to do
400 Bad Request	Malformed JSON, or the model field is missing.	Fix the request body.
401 Unauthorized	Missing, invalid, or revoked API key.	Check the key and the Authorization header.
403 Forbidden	A resource group pool was requested that your organization may not use ("resource group \"...\" requires VIP access").	Drop the pool suffix/header to use default routing, or ask support for pool access.
404 Not Found	Unknown model, or no serving endpoint for it ("No endpoints for model ...").	Pick a model from GET /v1/models.
405 Method Not Allowed	Wrong HTTP method for the path (only GET /v1/models and POST on the inference paths are accepted).	Check the method and path.
429 Too Many Requests	An org or per-key rate limit was exceeded.	Back off and retry; consider raising per-key limits or contacting support for a higher org tier.
502 Bad Gateway	Every upstream endpoint for the model failed after retries ("All endpoints failed for <model>. Last: ...").	Retry with backoff; if persistent, try another model or contact support.
503 Service Unavailable	Authentication or model routing temporarily unavailable.	Retry with backoff — this is transient and not caused by your request.
4xx/5xx (other)	Provider errors that we do not retry (e.g. a 400 for a malformed prompt) are passed through with their original status and body.	Handle per the provider’s error semantics.

Retry guidance

• Retry 429, 502, and 503 with exponential backoff and jitter. Rate-limit responses do not currently include a Retry-After header, so start around one second and double per attempt.
• Do not retry 400, 401, or 404 without changing the request.
• The platform already retries transient upstream failures internally — rate limits, 5xx, and vendor-side auth/quota rejections are failed over to another provider before you ever see a 502 — so client-side retries can be conservative.