Skip to main content

Error Response Format

All Autumn API errors follow a consistent JSON structure:

Response Fields

HTTP Status Codes

Autumn uses standard HTTP status codes to indicate the success or failure of requests:

Error Categories

Authentication Errors (401)

Errors related to API authentication and authorization.

Validation Errors (400)

Errors related to invalid input parameters or request validation.
Example: Validation Error

Idempotency Errors (400/409)

Errors related to idempotent request handling.

Organization Errors (404/400)

Errors related to organization operations.

Customer Errors (400/404)

Errors related to customer operations.

Product Errors (404/400)

Errors related to product and pricing operations.

Feature Errors (400/404)

Errors related to feature flag and entitlement operations.

Stripe Errors (400/500)

Errors related to Stripe payment processing.
Example: Stripe Error

Invoice Errors (400/500)

Errors related to invoice operations.

Event Errors (400/409)

Errors related to event tracking.

Rewards & Referral Errors (400/404)

Errors related to rewards and referral programs.

Entity Errors (400/404)

Errors related to entity operations.

Internal Errors (500)

Errors indicating server-side issues.
Example: Internal Error

Vercel Integration Errors (400/404)

Errors related to Vercel marketplace integration.

Migration Errors (400/409)

Errors related to data migration operations.

Error Handling Best Practices

Always check the HTTP status code before parsing the error response. This gives you a quick indication of the error category:
  • 4xx - Client errors (fix your request)
  • 5xx - Server errors (retry or contact support)
Use the code field for programmatic error handling, not the message field. Error messages may change, but codes remain stable:
For 5xx errors and certain 4xx errors (like rate limiting), implement exponential backoff retry logic:
Always log error responses (including the full response body) for debugging purposes, but ensure you don’t log sensitive data like full API keys.
For validation errors (invalid_inputs), parse the error message to provide specific feedback to users:
Never expose detailed error messages to end users. Error messages may contain sensitive information. Instead, show user-friendly messages and log the full error details for debugging.

Contact Support

If you encounter persistent errors or need help:
  • Check the Autumn documentation
  • Contact support with the error code and request ID
  • Include relevant logs (without sensitive data)