RexaThe short answer
Rexa can hold Telnyx, Twilio and Plivo credentials at once and order them by priority. Each dispatch takes the highest-priority healthy carrier and may fall back to two more. A carrier that fails five times in a row is pulled from rotation for sixty seconds, then re-tested with a single probe call. Only transient failures trigger a retry elsewhere.
Last reviewed
Telnyx, Twilio and Plivo as Rexa implements them
| Telnyx | Twilio | Plivo | |
|---|---|---|---|
| Credential fields you supply | api_key, voice_application_id (connection_id derived) | account_sid, auth_token | auth_id, auth_token, optional app_id |
| Validation call | GET /v2/call_control_applications/:id | GET /2010-04-01/Accounts/{SID}.json | GET /v1/Account/{AUTH_ID}/ |
| caller_id_name on /v1/phone-numbers | Populated | Always null | Always null |
| Number-inventory scoping | By Call Control Application | Whole account | By Application ID when set, else whole account |
| Provisioned by Rexa on the default path | Yes | No — bring your own | No — bring your own |
| Wired as an SMS provider | Yes | No | No |
| Inbound callback endpoints | One | One | Two (call and recording) |
How does Rexa choose which carrier to use?
Each provider row carries a `priority` integer between 0 and 10,000, defaulting to 100, where lower means preferred. Before every dispatch the router builds an attempt list: it drops carriers with no usable credentials, drops any whose circuit breaker is open, drops any the caller explicitly excluded, then sorts what is left by priority ascending.
A request can name a `preferred_provider`. If that carrier survives the filtering it jumps to the front of the list regardless of its priority; if it does not survive, the router quietly falls back to priority order rather than failing the call. The final list is capped at three attempts — a primary plus up to two fallbacks.
When does a carrier get taken out of rotation?
After five consecutive failures the breaker for that tenant-and-carrier pair opens, and dispatch through it is refused for sixty seconds. When the cooldown elapses the breaker moves to half-open and admits exactly one probe.
A successful probe closes the breaker and resets the failure count. A failed probe re-opens it and restarts the sixty-second clock, and the failure count stays at the threshold — so recovery always requires a good probe, never another five failures. Breakers are per tenant as well as per carrier, so one account’s problems never affect another’s routing.
Which failures actually trigger failover?
Timeouts, HTTP 429 and any 5xx are treated as transient and are worth trying on another carrier. Every other 4xx is treated as deterministic: the request is malformed or the destination is bad, so a second carrier would reject it too, and retrying risks paying for two legs to achieve the same failure. Rexa fails fast on those instead.
That distinction is the reason failover is safe to leave on. It only ever fires where a different carrier could plausibly succeed.
What happens when no carrier is available?
The router refuses with one of three reasons, and they are deliberately distinct because they need different responses: `no_candidates_configured` means nothing is set up, `no_healthy_provider` means everything configured is currently broken or in cooldown, and `all_providers_excluded` means a retry sequence has worked through the whole list.
Separately, a tenant with no enabled provider row at all gets HTTP 412 with `no_providers_configured` from the calls endpoint. That is a configuration error rather than a health problem, so it is reported before any routing is attempted.
Frequently asked questions
- Do I need more than one carrier?
- Most accounts do not. The default setup runs one carrier that Rexa provisions and configures. A second carrier is worth the extra credentials and the extra invoice when a calling operation is large enough that an hour of one carrier’s degradation is expensive.
- Can I force a specific carrier for one campaign?
- Yes. Pass `preferred_provider` on the request and that carrier moves to the front of the attempt list, provided it has credentials and its circuit is not open. If it has been pulled from rotation, the call still goes out on the next healthy carrier rather than failing.
- Does failover cost more?
- Rexa’s per-minute rate does not change. On the bring-your-own path each carrier bills you for the legs it carried, so a failed first attempt that never connected costs little, while a connected call that later failed is billed by whichever carrier carried it.
Scope, limitations, and sources
Failover only moves between carriers you have already configured and validated — a single-carrier account has nothing to fail over to, and adding a second carrier means holding a second set of credentials and a second invoice. It applies at dispatch, not mid-call: a conversation that is already connected does not migrate if that carrier degrades. Priority expresses preference, not guarantee; an open circuit outranks any priority you set. The three-attempt cap is fixed, so a fourth carrier can be configured but will not be reached in a single dispatch. None of this changes Rexa’s per-minute rate, and on bring-your-own each carrier invoices you for the legs it actually carried.
Sources
- Telecom provider credential fields, credential validation, priority ordering and circuit-breaker behaviour. rexa.ai (accessed )
- Placing calls over the REST API, including selecting a preferred provider. rexa.ai (accessed )
- The per-minute rate, what it includes, and how bring-your-own telecom is billed. rexa.ai (accessed )
Spotted something out of date or wrong? Tell us on the contact page and we will correct it and update the review date.