# API errors, limits and retries

Handle Problem Details, HTTP 400, 401, 403, 404, 429 and 503; honor Retry-After and distinguish unresolved from unavailability.

Canonical: https://iabula.com/docs/en/errors

## Structured errors

Failures use application/problem+json with type, title, status, code, detail and request_id. Use code for integration decisions and request_id for support. Do not depend on title or detail wording. Handle unsuccessful HTTP responses before reading success fields.

## What each status means

- 400: invalid parameter, schema or cursor. Correct the input before retrying.
- 401: missing, invalid or revoked credential.
- 403: unauthorized access/origin. Check your channel; do not supply internal secrets.
- 404: identifier not found in the catalog.
- 429: quota or request-rate limit. Honor Retry-After and check your plan.
- 500 or 503: internal failure or temporary unavailability. Use bounded retries and contact support if it persists.

## Retries without amplifying failures

Configure timeouts, maximum attempts and backoff with jitter. Honor returned Retry-After and avoid aggressive retries when a monthly quota is exhausted. Authenticated requests can count toward usage even when the response is an error; limits depend on channel and plan.

## unresolved is not an error

> A processed Resolve request with status unresolved returns HTTP 200 and resolved: null. Do not convert HTTP 503 into unresolved. Similarly, data: [] in Search or Relations is not a transport failure.

- [Authentication](https://iabula.com/docs/en/authentication)
- [Resolve contract](https://iabula.com/docs/en/resolve)

## Resources

- [OpenAPI JSON](https://iabula.com/openapi.json)
- [Swagger](https://iabula.com/docs/swagger)
- [Documentation index](https://iabula.com/llms.txt)