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.