Build resilient integrations with retries, idempotency, and graceful degradation.
AI inference is probabilistic infrastructure — upstream providers occasionally return errors, rate limits enforce usage ceilings, and networks misbehave. A robust integration handles these conditions without surfacing failures to your users.
The 429 rate_limit_exceeded and 503 temporary_unavailable responses both include a Retry-After header. Honor it — retrying sooner wastes your request budget.
Add a small random jitter (e.g. random.uniform(0, 1) seconds) to prevent a thundering herd when multiple workers retry simultaneously.
Inference requests are not idempotent by nature — retrying a request may produce a different response. For workflows where duplicate processing matters (billing actions, database writes triggered by AI output), add your own deduplication layer keyed on a request ID that you generate client-side.
Pass your ID in the X-Request-Id request header. OpenDunes will echo it in the response header, making it easy to correlate logs.
Design for failure states so your product keeps working:
Each response includes the X-Balance-Available header (remaining micro-DA). Poll it or subscribe to low-balance email alerts from your dashboard to avoid surprise 402 errors in production.
Pass an ordered models array (up to 4 slugs) instead of a single model — if the primary errors or is unavailable, OpenDunes retries the next model in the list automatically. See Model Fallbacks. Provider-level failover within a model rides on provider.allow_fallbacks (on by default).
For the full list of status codes and their meanings, see the Errors reference page.