Queue SLA breach: worked SDK samples
The per-queue SLA pipeline (objective → forecast → breach → escalation) is mapped on the parent page; this page is the runnable half — every call below ships the full request body, dereferencesdata the same way the cURL response frames it, and unwraps the success envelope (data + meta.request_id + meta.timestamp) the way every Orbit endpoint returns it. No typed helper covers the sla-breach routes yet in any SDK, so each sample uses the generic request escape hatch with the queue id in the path.
PUT the breach policy
cURL first, then Node and Python:Node SDK
Python SDK
GET .../sla-breach/policy; remove it entirely with DELETE there — a queue with no policy logs nothing, gates nothing, and alerts nothing.
POST a breach scan
Feed a measured window (from the queue stats endpoints or your own aggregation) to the scan and it returns the verdict —breached, observed_service_level, alert_fired (the surfaces that fired, e.g. ["bell","webhook"]), plus policy_configured, event_logged, and cooldown_active:
Node SDK
GET the breach event log
Newest-first audit of every breach the pipeline recorded (the queue’s ring buffer holds at most 200 entries; the endpoint returns the newest 50 by default,?limit= up to 100):
Go SDK
Request bodies per breachAction
breachAction takes one of five values; every body below is a complete PUT payload for /sla-breach/policy — only the action differs:
open_ticket — org-admin inbox item
page_supervisor — outbound tenant webhook your paging tool subscribes to
reroute_to_overflow_queue — both the inbox item and the webhook
enqueue_callback — webhook for downstream callback automation
none — log the breach, alert nothing
ORBIT_API_KEY to a sandbox key (dv_test_sk_...) first — the policy write and scan behave identically against sandbox and live keys, and no SDK call here sends a call.