Get SLA by ID
/v1/slas/{id}org.permission.sla.readorg.user.sla.readThe API key or user must hold at least one of them. Legacy roles still work; prefer the others for new keys.
Retrieves an SLA based on the unique SLA ID.
Use the optional versions query param to retrieve information about SLA versions.
Included SLA version metrics may configure nextReply (Next Reply time targets per priority) and optional basedOnHumanInteraction on firstResponse and nextReply. When basedOnHumanInteraction is true, only human-authored SENT outbound messages satisfy the metric. When omitted or false, any customer-visible SENT outbound satisfies it (legacy behavior).
SLAs
An SLA (service level agreement) is a response-time policy, such as "reply to urgent emails within one hour". Kustomer matches each conversation to one SLA and tracks deadlines for it, so agents can see what's about to breach and managers can report on what did.
Admins define SLAs in the Kustomer admin settings. Each SLA has criteria that decide which conversations it covers, such as a channel or queue, and target times for one or more metrics. SLAs are kept in an order. As conversations change, Kustomer applies the first SLA in that order whose criteria match, then stamps the result on the conversation's sla attribute: the SLA name and version, matchedAt, a deadline (breachAt) and satisfiedAt for each metric, and whether and when it breached. That conversation attribute is where you read live SLA state. The SLA object itself is the policy.
Versions
SLAs are versioned. Every edit creates a new version, currentVersion points at the latest, and a conversation records which version it was matched against, so older conversations keep the targets they were measured on. GET /v1/slas/{id} returns the SLA's ID and version list; add versions=active to include the current version's full definition in included, or versions=all to include every version.
Metrics and targets
A version's metrics can enable any of these:
| Metric | Measures |
|---|---|
firstResponse |
Time from the start of the conversation to the first outbound reply. |
nextReply |
Time to answer each new customer message after the first. |
longestUnrespondedMessage |
Time from the customer's latest message to an agent reply. |
totalConversationOpenTime |
Total time open until done, not counting time snoozed. |
totalCustomerWaitTime |
Total time the customer waited for replies, including time snoozed. |
Each metric's times holds a target in milliseconds for each conversation priority, keyed 1 to 5; conversations without a priority use 3. When basedOnHumanInteraction is true on firstResponse or nextReply, only messages written by a person satisfy the metric, so automated replies don't stop the clock.
Business hours
hours is calendar or business. Calendar SLAs count every minute. Business SLAs count only while a business schedule is open, skipping nights, weekends and enabled holidays, so a one-hour target set at 4:30 pm on a Friday may not breach until the next business day. A business-hours SLA uses the schedule set on the SLA, or the org's default schedule if none is set.
Which endpoint to use
| To | Call |
|---|---|
Look up the policy behind a conversation's sla, including its targets |
GET /v1/slas/{id}, with versions=active or versions=all |
The documented API only reads SLAs; admins create and edit them in the admin settings. To find conversations by SLA state, search on attributes such as conversation_sla_breached, conversation_sla_breach_at and conversation_sla_status (pending, paused or done) rather than reading conversations one by one.
Path parameters
Unique SLA ID.
"5fadc1ba6647f1953ff94916"Query parameters
Option to include information about SLA versions. Use all to retrieve information about all versions. Use active to retrieve information about the active version only.
activeallExample "active"Responses
Success