Skip to main content

Error Response Format

All errors follow a consistent format:
{
  "status": "failed",
  "message": "Error description"
}

HTTP Status Codes

200 OK
object
Request successful
201 Created
object
Resource created successfully
400 Bad Request
object
Invalid request parameters or malformed request body
401 Unauthorized
object
Invalid or missing API key
403 Forbidden
object
Business does not have an active subscription required for the Developer API
404 Not Found
object
Resource not found
500 Internal Server Error
object
Server error. Please contact support if this persists.

Common Errors

Invalid API Key

401 Unauthorized
object
{
  "status": "failed",
  "message": "Invalid API key. Please check your API key and try again."
}
Solution: Verify your API key is correct and included in the request header.

No Active Subscription

403 Forbidden
object
{
  "status": "failed",
  "message": "Your business must have an active subscription to use the Developer API. Please upgrade your subscription to continue."
}
Solution: The Developer API requires a paid subscription. Upgrade your subscription plan to continue using the API.

Resource Not Found

404 Not Found
object
{
  "status": "failed",
  "message": "Invoice not found"
}
Solution: Check that the UUID or source_uuid exists and is correct.

Invalid Request Body

400 Bad Request
object
{
  "status": "failed",
  "message": "Invalid request body. Missing required field: prompt"
}
Solution: Ensure all required fields are included in your request body.

Rate Limiting

API rate limits may apply. Check response headers for rate limit information:
  • X-RateLimit-Limit: Maximum requests per time window
  • X-RateLimit-Remaining: Remaining requests in current window
  • X-RateLimit-Reset: Time when rate limit resets
If you exceed rate limits, you’ll receive a 429 Too Many Requests response. Implement exponential backoff in your integration.

UUID Resolution

All update and delete operations support both uuid and source_uuid for record identification. The API automatically checks both fields when looking up records. Example:
  • If you have a record with uuid: "abc-123" and source_uuid: "xyz-789"
  • You can use either abc-123 or xyz-789 in the endpoint URL
  • Both will resolve to the same record

Best Practices

  1. Always check status codes before processing responses
  2. Handle errors gracefully with appropriate user feedback
  3. Implement retry logic for transient errors (5xx status codes)
  4. Respect rate limits by implementing request throttling
  5. Log errors for debugging and monitoring