API Errors and HTTP Status Codes

ReachOwl returns standard HTTP status codes. 401 means your token is missing or invalid. 422 means validation failed. 404 means the resource was not found.

ReachOwl uses conventional HTTP status codes to indicate the success or failure of every API request. Understanding these codes helps you build reliable integrations and respond correctly when something goes wrong. All API responses require the Accept: application/json header.

Status code reference

Code	Name	Meaning
200	OK	The request succeeded. Used for successful GET, PUT, and DELETE operations.
201	Created	The resource was created successfully. Returned by POST create endpoints.
204	No Content	The request succeeded but there is no content to return.
400	Bad Request	The request was malformed or contained invalid parameters.
401	Unauthorized	Your Bearer token is missing, expired, or invalid. Check the Authorization header.
403	Forbidden	You do not have permission to access the requested resource.
404	Not Found	The requested resource does not exist. Verify the ID or path.
422	Unprocessable Entity	Validation failed. The request body contains fields that are missing, incorrect, or out of range.
429	Too Many Requests	You have exceeded the rate limit. Wait before retrying the request.
500	Internal Server Error	An unexpected error occurred on ReachOwl’s servers. Retry later or contact support.

Common error scenarios

Missing or invalid token

If you receive a 401 response, verify that your request includes the header:

-H "Authorization: Bearer {{token}}"

Validation errors

A 422 response means one or more fields failed validation. Check the response body for details about which fields are required or have incorrect values. For example, creating a campaign without a required action_type will return 422.

Rate limiting

If you receive 429, back off and retry with exponential delay. ReachOwl may temporarily throttle high-volume callers to protect platform stability.

Retrying failed requests

For 500 errors and occasional 429 responses, implement an exponential backoff retry strategy. Do not retry 400, 401, 403, 404, or 422 responses because the request itself is unlikely to succeed without changes.

Related pages

• /api-reference/introduction — API overview and base URL
• /authentication — how to obtain and use your Bearer token