Skip to main content

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, dereferences data 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
Read it back with 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
Set 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.