Skip to main content

Error envelope

All errors return a JSON body in this shape:

HTTP status codes

Error types

Common error codes

Authentication and authorization

Validation

Resource state

order_not_spendable — terminal orders never spend carrier money

Arcus refuses to buy a carrier label, or to arm a future label purchase, against an order that has reached a terminal state. This is a hard safety rail: a carrier charge on a closed order is real money that then has to be voided and reconciled by hand. An order is terminal for this purpose when order_status is one of: Statuses that are not terminal and continue to buy labels normally: open, processing, fulfilled (return-to-sender reships and re-labels are legitimate), and awaiting_ach_clearance (pack-ahead). Endpoints that return this error: Example response:
How to resolve: reinstate the order if it is live again, or create a new order for the shipment. Retrying the same call will not succeed — this state never heals on its own, so treat it as permanent and do not put it in a retry loop.
The check runs immediately before Arcus calls the carrier, not at the start of the request. An order cancelled while a label purchase is already in flight is still refused.

Expand

Rate limits

Handling errors in code

Retry strategy

  • 5xx errors: safe to retry with exponential backoff (1s, 2s, 4s, 8s, max 5 retries)
  • 429 errors: wait the number of seconds in the Retry-After response header before retrying
  • 4xx errors (except 429): do not retry; fix the request first
  • Always use Idempotency-Key on retried POST/PATCH/DELETE requests to prevent duplicates

Support

Include request_id when contacting support. It allows the Arcus team to retrieve the full trace for the failing request.