.svg)
This page covers how the Enpass Business API communicates errors, what the common error codes mean, and how to handle them gracefully in your integration.
Error Response Structure
When a request fails, the API returns a JSON object with the following fields:
|
Field |
Type |
Description |
|---|---|---|
|
|
boolean |
|
|
|
string |
A machine-readable error code identifying the type of failure |
|
|
string |
A human-readable message describing what went wrong |
Example error response:
{
"error": true,
"code": "unknown_error",
"description": "Something went wrong"
}
HTTP Status Codes
|
Status Code |
Meaning |
What to Do |
|---|---|---|
|
|
Request succeeded |
Process the response normally |
|
|
Missing or Invalid Bearer token or Invalid Token Scope |
Verify your token and ensure it is included in the |
|
|
Endpoint path is incorrect |
Check the endpoint URL and ensure your base URL is correct |
|
|
Rate limit exceeded |
Back off and retry after a short delay; see Rate Limits below |
|
|
Server-side failure |
Retry the request; if the issue persists, contact Enpass support |
Rate Limits
The API enforces a limit of 30 requests per minute per token. Exceeding this limit returns an HTTP 429 response.
Recommendations to avoid rate limit errors:
-
Cache responses where the underlying data does not need to be real-time. The Security Audit Summary and Adoption Summary endpoints are good candidates for caching.
-
Implement exponential backoff — wait progressively longer between retries after a
429response. -
Batch filters — use
vault_filterson the Vault Summary API endpoint to retrieve targeted data in fewer calls rather than paginating broadly.
Common Error Code
|
Code |
Description |
|---|---|
|
|
A general server-side error occurred. Retry the request or contact Enpass support if it persists |