Skip to main content
Every 4xx and 5xx response from the Payouts API carries a structured error body so you can handle failures programmatically. For the HTTP status codes themselves, see Status Codes.

Error response shape

Every error response - for any 4xx or 5xx - has the same JSON body: a single error object.
Build your error handling against type and code, never against message. Messages are meant for humans and may change at any time; the type and code values are stable contracts.

Error types

type groups every error into one of the following categories. It maps directly to the HTTP status class, so you can branch on either.

Error codes

The full set of code values, grouped by type.

invalid_request_error - 400

authentication_error - 401

authorization_error - 403

not_found_error - 404

conflict_error - 409

service_unavailable_error - 503

internal_error - 500

For any 5xx response the message is always the generic "An unexpected error occurred" and the code is always INTERNAL_ERROR, regardless of the underlying cause - internal details are never echoed back to the caller. Rely on the HTTP status class to detect server-side failures, and contact support with your request context if they persist.

Idempotency

Write operations accept an Idempotency-Key request header. Sending the same key again returns the original result instead of performing the operation twice, which makes it safe to retry after a network error or a 5xx.
  • Reusing a key with a different request body returns 409 conflict_error / IDEMPOTENCY_KEY_REUSED.
  • Retrying while the first request is still in flight returns 409 conflict_error / IDEMPOTENCY_KEY_IN_PROGRESS - wait and retry.
  • If the idempotency store is temporarily down, you’ll get 503 service_unavailable_error / IDEMPOTENCY_STORE_UNAVAILABLE - retry the request.