Routing policies
Apian Labs Relay routing policies define provider ordering, retry behavior, and cooldown windows for a segment. This page explains the policy model so you can tune deterministic failover for your most important messages.
Policy structure
A policy includes a segment label, a primary provider, one or more secondary providers, and retry rules. Apian Labs Relay evaluates policies consistently so routing does not drift under load or during incidents.
{
"segment": "incident",
"primaryProvider": "twilio",
"secondaryProviders": ["telnyx"],
"retryPolicy": {
"maxAttempts": 2,
"retryableErrors": ["timeout", "provider_5xx", "rate_limited"],
"backoff": { "baseMs": 200, "maxMs": 2000, "jitter": "full" }
},
"cooldownSeconds": 300
}
Retry policies can also set jittered backoff (base/max delay and jitter mode) to smooth retries during provider incidents.
Deterministic failover
Apian Labs Relay only fails over for retryable provider failures such as timeouts, server errors, and rate limiting. Non-retryable errors surface immediately so your application can decide the next step.
Cooldowns and retries
After failover, the primary provider enters a cooldown window before it is eligible again. This prevents routing from bouncing back to an unstable provider too quickly. Relay defaults to two attempts with jittered backoff when no retry policy is specified. Cooldowns are only applied when more than one provider is configured.
Managing policies
Policies are created and updated in the dashboard today. API-based policy management is planned, and the documentation will be updated when it is available.