Fiest Developers

API error codes

Stable error codes, retry guidance, and support correlation IDs.

Fiest API errors use a stable machine-readable error code. Responses may also include a safe message or error_description, plus a request_id that you should include when contacting Fiest support.

For support, email support@fiest.io with the request_id, API environment, endpoint, HTTP method, status code, and UTC timestamp. Never send an access token, refresh token, authorization code, cookie, or customer financial payload.

Error codeHTTP statusRetry automaticallyMeaning
authorization_expired403NoThe authenticated authorization no longer resolves an accessible restaurant. Ask the customer to authorize the integration again.
capability_disabled503YesThe capability is documented but is not enabled in the current Fiest environment.
conflict409NoThe requested change conflicts with the current restaurant state or a platform limit.
idempotency_conflict409NoThe supplied idempotency key was already used for a different request.
insufficient_scope403NoThe access token does not include every scope required by the operation.
invalid_request400NoA path or query parameter is missing, malformed, or outside its supported bounds.
invalid_token401NoThe bearer token, approved client, consent, membership, organization grant, or authorizer role is missing, expired, revoked, or invalid for this API.
managed_externally409NoThe requested setting is managed by an active external integration and cannot be changed through this API.
not_found404NoThe resource does not exist or is outside the current authorization boundary.
payload_too_large413NoThe JSON request body exceeds the documented size limit.
precondition_failed409NoThe restaurant state changed after it was reviewed. Fetch the latest state and build a new request.
rate_limited429YesThe partner request limit was exceeded. Wait for the Retry-After duration before retrying.
service_unavailable503YesFiest or a required downstream service is temporarily unavailable.
write_in_progress409YesAn idempotent write is still processing. Retry the exact request with the same idempotency key after Retry-After.

Retry safely

  • For rate_limited, wait for the response's Retry-After duration.
  • For service_unavailable, use capped exponential backoff with jitter.
  • For write_in_progress, wait for Retry-After and resend the exact request with the same idempotency key.
  • For precondition_failed, fetch the latest state and build a new request; do not resend the stale request automatically.
  • Do not repeatedly retry authorization, scope, validation, or not-found errors.
  • A refreshed access token can resolve invalid_token when a valid rotating refresh token is available. Otherwise, ask the customer to reconnect.

Never parse the human-readable message for application logic. Match the error value and retain the request_id for diagnostics.

On this page