Skip to main content

Errors

Understanding how the Knowhere API communicates errors helps you build reliable integrations. Errors can surface in two ways — as HTTP error responses from the API, or as job failures reported asynchronously when a parsing job fails.

HTTP Errors​

The API uses standard HTTP status codes with canonical error codes:

Client Errors (4xx)​

HTTPError CodeDescriptionRetryable
400INVALID_ARGUMENTInvalid request format or contentNo
400FAILED_PRECONDITIONSystem state prevents the operationNo
401UNAUTHENTICATEDMissing or invalid API keyNo
402PAYMENT_REQUIREDInsufficient creditsNo
403PERMISSION_DENIEDAPI key lacks required permissionNo
404NOT_FOUNDResource does not existNo
409ALREADY_EXISTSResource already existsNo
409ABORTEDConcurrency conflictYes
429RESOURCE_EXHAUSTEDRate limit or quota exceededConditional
Current 429 Semantics

In the current API implementation, polling RPM limits, job-creation RPM limits, daily quota checks, and concurrent active-job caps all surface as RESOURCE_EXHAUSTED with details.reason = "RATE_LIMIT_EXCEEDED".

Use details.period to tell them apart:

  • minute: per-minute rate limit
  • day: daily job-creation quota
  • concurrent: active-job concurrency cap

The Retry-After response header is the canonical retry hint.

Server Errors (5xx)​

HTTPError CodeDescriptionRetryable
500INTERNAL_ERRORInternal server errorYes
500UNKNOWNUnexpected error (fallback)Yes
503UNAVAILABLEService temporarily unavailableYes
504DEADLINE_EXCEEDEDRequest timed outYes

Server errors are generally safe to retry with exponential backoff. The SDK retries these automatically.

Job Failure Errors​

Because Knowhere processes documents asynchronously, some errors only surface when a job reaches the failed state. These are reported in the error object on the job response — not as HTTP errors.

Error Shape​

All HTTP error responses follow a consistent JSON envelope:

{
"success": false,
"error": {
"code": "NOT_FOUND",
"message": "Job not found",
"request_id": "req_abc123def456",
"details": {
"resource": "Job",
"id": "job_xyz789"
}
}
}
FieldTypeDescription
codestringMachine-readable error code (see tables above)
messagestringHuman-readable, user-safe description
request_idstringUnique identifier for this request or job
detailsobjectAdditional structured context (varies by error type)
note

The message field always contains a user-safe description. Internal debugging details are never exposed in the response — they are only captured in server logs.

Common Detail Schemas​

Different error codes provide different details structures:

Validation errors (INVALID_ARGUMENT):

{
"violations": [
{ "field": "file", "description": "Exceeds 100MB limit" }
]
}

Rate limit errors (RESOURCE_EXHAUSTED):

{
"reason": "RATE_LIMIT_EXCEEDED",
"retry_after": 15,
"limit": 200,
"period": "minute"
}

Not found errors (NOT_FOUND):

{
"resource": "Job",
"id": "job_abc123"
}

Insufficient credits (PAYMENT_REQUIRED):

{
"required_credits": 10.0
}

Request ID​

Every API response includes a request_id in the error body. When contacting support about a specific request or job, always include this ID — it lets us trace the exact request through our systems.

Retry Strategy​

What to Retry​

CategoryRetry?Strategy
UNAVAILABLE (503)YesExponential backoff
DEADLINE_EXCEEDED (504)YesExponential backoff
INTERNAL_ERROR (500)YesExponential backoff
RESOURCE_EXHAUSTED (429)ConditionalWait details.retry_after seconds
ABORTED (409)YesRetry immediately
All other 4xxNoFix the request first

Built-in SDK Retries​

The Python SDK automatically retries connection errors, 429, and ≥500 errors with exponential backoff:

client = knowhere.Knowhere(
api_key="sk_...",
max_retries=3, # default is 5
)

Getting Help​

If you encounter persistent errors:

  1. Note the request_id from the error response
  2. Check the status page for outages
  3. Contact support at team@knowhereto.ai

Include the full error response (without your API key) and when the error occurred.