Does failover guarantee a response?

No. It depends on configured eligible routes, model availability and the request’s retry rules. Applications still need failure and recovery states.

Will the gateway silently choose a different model?

Request the exact model you need. Route selection for that model is distinct from choosing a different model in your application.

Should I retry a timed-out video submission?

Do not blindly repeat a paid submission. If you have a task ID, resume status polling. Otherwise investigate the uncertain outcome before creating another task.

ALLGATE / DEVELOPER WORKFLOW GUIDE

Understand LLM API failover and AI gateway routing.

API failover can move an eligible request between configured routes when the gateway’s retry rules allow it. It does not create unlimited model supply or guarantee uptime. Design your application to distinguish a rejected request, a broken stream and a paid task whose submission result is uncertain.

Read the endpoint reference API quickstart →

01 / WORKFLOW

Understand what makes a route eligible

The gateway can select only configured routes for the requested model and protocol that satisfy access and health requirements. Operator priorities still apply. A model identifier is not an instruction to substitute an unrelated model. The public catalogue exposes availability, while supplier costs and private routing details remain outside the customer interface. Check current availability instead of assuming a historical listing is callable.

02 / WORKFLOW

Separate speed preferences from commercial discounts

Allgate’s Speed option uses standard pricing and prefers faster observed healthy eligible routes within operator priorities. It is a routing preference rather than a fixed latency guarantee. AI savings and assigned business terms describe pricing rules, not an unlimited pool of fallback capacity. Review the pricing policy and the effective quote separately from reliability decisions in your application.

03 / WORKFLOW

Recover according to the request’s actual state

For ordinary requests, classify authentication, validation, quota and upstream errors before choosing a retry policy. A stream interrupted after output begins needs an explicit partial-result state; blindly retrying can duplicate visible content. For asynchronous video, persist the task ID and resume polling. For image, speech or video submission with an unknown outcome, investigate using request context rather than creating another paid job.

Check models and current availability

These entries come from the public catalogue build snapshot. A listing does not guarantee endpoint capability or continuing supply. For audio, verify synthesis or transcription support separately. Open a model to check its exact ID, settings and billing unit.

Catalogue snapshot: 2026-10-30

Compare live models and API pricing →

Costs and workflow limits

Keep request identifiers, task IDs and usage records so application events can be reconciled with account billing. Do not treat an HTTP timeout as proof that no provider work occurred. Test failures against the sandbox or a local mock, and do not run paid production calls merely to validate a retry loop.

Review API pricing and prepaid credits →

COMMON QUESTIONS

Before you integrate

Does failover guarantee a response?: No. It depends on configured eligible routes, model availability and the request’s retry rules. Applications still need failure and recovery states.
Will the gateway silently choose a different model?: Request the exact model you need. Route selection for that model is distinct from choosing a different model in your application.
Should I retry a timed-out video submission?: Do not blindly repeat a paid submission. If you have a task ID, resume status polling. Otherwise investigate the uncertain outcome before creating another task.