Frayme can route around a degraded provider automatically. The Fallback Rules panel binds a primary provider to a secondary one in the same category; when the primary returns degraded or disconnected, calls are transparently re-routed.
Anatomy of a rule
| Field | Meaning |
|---|
| Primary | The provider workflows would normally hit. |
| Fallback | The replacement. Must be in the same category as the primary. |
| Notify admin | If true, sends a notification to the admin team when the fallback activates. |
| Enabled | Disable to keep the rule in place but inactive. |
Sanctions/AML provider for a Device Fingerprint one.
Failover triggers
A fallback activates when:
- the primary’s last health probe is
disconnected; OR
- the primary’s
success_rate < 95% over the last 5 minutes; OR
- the primary times out N+1 times in succession (N =
retryCount on the node).
Example: KYC liveness
| Primary | Fallback | Reason |
|---|
| Jumio | Socure | Jumio reports degraded; Socure picks up identity verification calls. |
| Sumsub | — | Resold, no fallback wired (Frayme manages SLA upstream). |
Resold providers (Sumsub, LSEG, BigDataCorp, Crystal) don’t ship with a default fallback. Their SLA is held by Frayme; routing around them silently would mask an issue Frayme needs to see.
What happens to in-flight calls
Mid-flight calls already issued against the primary continue to be awaited. New calls — including retries on the same node — start hitting the fallback. The workflow’s audit log records both the original target and the routed target.