The golden rule
Never crash on an API error. Every integration should gracefully degrade when Arcus is unavailable, rate-limited, or returns a validation error.Error classification
Before writing retry logic, classify errors by whether they are safe to retry:| Class | Examples | Retry? |
|---|---|---|
| Transient | 500, 502, 503, 504, network timeout | Yes, with backoff |
| Rate limited | 429 | Yes, after Retry-After seconds |
| Client error | 400, 401, 403, 404, 409, 422 | No — fix the request first |
Exponential backoff
For transient errors and rate limits, use exponential backoff with jitter:Idempotency on retry
Always useIdempotency-Key when retrying POST/PATCH/DELETE requests. Generate the key before the first attempt and reuse the same key on every retry:
Handling specific errors
401 Unauthorized
Your API key is missing, invalid, or expired. Check:Authorizationheader is present and starts withBearer- Key has not been deleted in Settings > Developers
- Key is for the correct mode (test vs live) for the environment you are calling
403 insufficient_scope
Your key lacks a required scope. The error includesrequired: <scope>:
404 not_found
The resource does not exist or belongs to a different entity. Common causes:- Typo in the ID
- Using a test-mode ID with a live-mode key
- The record was deleted
409 conflict
State conflict. Common causes:idempotency_key_mismatch: same key reused with a different body — generate a new keyresource_in_use: cannot delete a resource that is referenced elsewhere — see thereferencesfield in the error body for what is blocking the delete
422 Unprocessable Entity
Validation failure. Theparam field identifies which field failed and hint explains why:
Structured error logging
Log enough context to debug without logging sensitive data:Circuit breaker
For high-volume integrations, add a circuit breaker to avoid hammering a degraded API:Monitoring
Set up alerts on:5xxerror rate spike (Arcus outage)429rate rising (approaching rate limit; add backpressure or request a limit increase)401/403errors (key expiry or accidental deletion)
request_id in your alert payloads so on-call engineers can share it with Arcus support.
