View and clear spend-anomaly auto-mitigations

​

When the detector stamps an auto-mitigation

• Clamp-down only. A mitigation can only lower the channel’s effective per-minute cap. It never raises a cap you configured, so it can never weaken protection you already have.
• Self-expiring. Every record carries an expiry at most six hours after it was applied, and a detection late in the UTC day expires sooner. When it expires, the channel’s normal caps apply again with nothing to do.
• Per-channel. Only channels with an enforced per-minute cap are auto-mitigated: sms, whatsapp, rcs, email, and voice. A surge elsewhere still raises an alert and a fraud review, but nothing is throttled.

​

View the active list in the dashboard

1. Open Settings, then Compliance.
2. Find the Active auto-mitigations panel.
3. Read the rows. Each one shows the channel, the action in force (Paused or Throttled to N/min), the time it was applied, and the time it auto-clears, all in your local timezone.

​

List active mitigations via API

curl -s https://orbit.devotel.io/settings/compliance/fraud-mitigations \
  -H "Authorization: Bearer $ORBIT_API_KEY"

{
  "data": {
    "mitigations": [
      {
        "channel": "sms",
        "mode": "pause",
        "max_per_min": 0,
        "severity": "critical",
        "applied_at": "2026-10-12T08:15:00.000Z",
        "expires_at": "2026-10-12T14:15:00.000Z"
      }
    ]
  }
}

{
  "data": {
    "mitigations": []
  }
}

​

Lift a mitigation early

curl -s -X DELETE \
  https://orbit.devotel.io/settings/compliance/fraud-mitigations/sms \
  -H "Authorization: Bearer $ORBIT_API_KEY"

• 200 when the clear is recorded, including the no-op case where the record had already expired.
• 403 when the calling user is not an organization owner.
• 422 when :channel is not one of sms, whatsapp, rcs, email, voice, or all.
• 503 on a transient datastore fault. The mitigation is still active in this case; retry after a few seconds.

​

When not to clear

• A new campaign, customer, or market ramp your baseline could not yet know about.
• A planned burst you recognize, such as a scheduled send window or a dialer shift.
• A retry storm from your own clients after an outage you have already resolved.

• You cannot match the volume to any campaign, queue, or dialer plan you started.
• An API key or dashboard session may have leaked. Rotate credentials and review recent sends before you lift anything; Fraud review triage walks the review.
• The surge returns immediately after a clear. If the detector re-applies a mitigation, the underlying velocity has not changed, and clearing again only extends the burn. Investigate first.

​

Observability

• Every clear writes an audit-log row with the action settings.fraud_mitigation_cleared, recording who lifted which channel and when. It lands in the same ledger as your other settings changes; see Audit ledger model.
• The Active auto-mitigations panel and GET /settings/compliance/fraud-mitigations reflect the clear immediately, because both read live settings rather than a cache.
• The channel’s effective cap reverts on the next send or dial, so refusals caused by a pause stop at that point. Traffic counters and dashboards resume accruing at the normal rate from then on.
• On the apply side, the detector also opens a fraud review and sends you an alert when it stamps a mitigation, so a clear never erases the evidence that something surged; see Spend anomaly and alert model.

​

Ask for evidence before you clear

1. Open your spend-anomaly alert rules (Usage anomaly alerts, Usage anomaly alert rules) and compare the projected spend against the baseline it used.
2. Read the anomaly entry behind the alert: baseline, current, and projected spend, plus the mitigation that was applied.
3. Clear when the projection is out of line with traffic you can explain. Keep the pause when it matches traffic you cannot.

• Spend anomaly and alert model
• Anomaly insights model
• Fraud caps
• Spend caps