Skip to main content
The Widgetic API uses standard HTTP status codes and returns detailed error information in the response body. All errors follow a consistent format with machine-readable codes, human-readable messages, and actionable guidance.

Error Response Format

HTTP Status Codes


Error Code Reference

Authentication Errors (401)

Errors related to verifying your identity.

Authorization Errors (403)

Errors related to permissions and access control.

Plan restrictions

Advanced analytics, A/B testing, translations and inviting teammates are part of the Teams plan. A request for one of them from an account on another plan fails with AUTHZ_PLAN_RESTRICTION, and the response says which capability was needed and what would unlock it:

Validation Errors (400)

Errors related to request format and data validation.

Resource Errors (404, 409, 410)

Errors related to resource existence and conflicts.

Rate Limiting Errors (429)

Errors related to request frequency limits.
When you receive a 429 response, check the Retry-After header for the number of seconds to wait before retrying.

Quota Errors (402, 413, 429)

Errors related to usage limits and billing.

Business Logic Errors (409, 422)

Errors related to business rules and state conflicts.

Partner Errors (402, 403, 404, 409, 422, 429, 502, 503)

Errors a partner integration meets: the standing of the account, its storage, its customers and what they may spend. Branch on error.code; error.details carries the machine-readable facts. Each page of the guide lists the errors of its own calls too.

External Service Errors (502, 503, 504)

Errors related to third-party dependencies.

System Errors (500, 503)

Internal system errors.

Handling Errors

JavaScript/TypeScript

The SDK throws a ResponseError for every answer that is not a success. The HTTP status is error.response.status, the response headers are error.response.headers, and the body is the error format shown above: read it with await error.response.json(). error.code holds the machine-readable code from that body.

Using Correlation IDs

Every error response includes a correlationId. Include this when contacting support:

Retry Strategies

Exponential Backoff

For transient errors (429, 503, 504), implement exponential backoff:

Idempotent Retries

For POST/PUT operations, use idempotency keys to safely retry:
See Idempotency for more details on safe retries.
A 409 with the code CONFLICT_IDEMPOTENCY_IN_PROGRESS means your earlier request with the same key is still running. It is safe to retry: wait for the Retry-After header and resend with the same key. A 409 with the code CONFLICT_IDEMPOTENCY_ANSWER_UNAVAILABLE means that request already succeeded and was not run again, but its response can no longer be returned: do not retry it with the same key; see When the stored response is no longer available. Any other 409 is not retryable as-is.

Best Practices

Never assume API calls will succeed. Always wrap calls in try/catch and handle specific error codes.
Store correlation IDs in your logs for debugging and include them in support requests for faster resolution.
For rate limiting (429), use exponential backoff with jitter. Always check the Retry-After header.
Validate data client-side before making API calls to catch validation errors early and reduce unnecessary requests.
When you receive AUTHZ_PLAN_RESTRICTION or QUOTA_* errors, provide users with clear upgrade paths or alternatives.