Errors
One error envelope across every endpoint
Every error response from the Plextera Public API uses one envelope, so you can write a single error handler for all endpoints.
You can send your own X-Request-Id header with any request. Plextera echoes it back in the response and in error payloads, which makes cross-system log correlation trivial.
Error codes
Retry guidance
- Retry only when
retryableistrueor the HTTP status is5xx. - On
429, wait for theRetry-Afterheader (seconds) before retrying. Prefer event subscriptions over tight polling to stay within rate limits. - Use exponential backoff with jitter; start around 1 second and cap at 30–60 seconds.
- Creation endpoints are not idempotent: if a
POST /document-insights/extractionsrequest times out client-side, list recent extractions (filtered by yourtags) before blindly retrying, or you may create a duplicate extraction.
API errors vs. processing failures
The error envelope above describes request failures: the API rejected or could not handle the HTTP call.
A successfully accepted document can still fail processing later. That outcome is not an HTTP error: the extraction or workflow run is returned with status FAILED or REJECTED and a RunError object (error.code, error.message) inside the resource payload. See Document Extraction — Handle failures.
Related reference
- API Reference - per-endpoint error responses
- Event Subscriptions - webhook delivery retry behavior