Get snooze by ID
/v1/snoozes/{id}org.permission.snooze.readThe API key or user must hold at least one of them. Legacy roles still work; prefer the others for new keys.
Fetches a snooze based on the ID.
Snooze options
Snooze options are the preset choices, such as "2 Hours" or "Tomorrow", that agents pick from when they snooze a conversation or custom object. Each option says how to work out the wake-up time; snoozing hides the item until then and reopens it when the time comes.
Snoozing parks work an agent can't finish yet. In the agent desktop, the snooze menu lists the org's enabled snooze options, and admins manage that list in the admin settings. When an agent picks one, the conversation's status becomes snoozed and its snooze attribute records when it should wake. At that time Kustomer sets it back to open. A customer reply also reopens a snoozed conversation early. These endpoints manage the menu of options, not individual snoozed conversations: to snooze or unsnooze a conversation, update the conversation itself.
Option types
type |
value |
Example |
|---|---|---|
relative |
A duration in milliseconds from the moment of snoozing. | 7200000 for "2 Hours" |
dynamic |
An object with a day rule and a time of day. |
{ "day": { "type": "tomorrow", "value": "" }, "time": "09:00 am" } for "Tomorrow", or "type": "absolute", "value": "monday" for "Next Week" |
absolute |
A fixed date and time, as a timestamp in milliseconds. | The end of a promotion |
name is the label in the menu, and enabled: false hides an option without deleting it. New orgs start with "Tomorrow", "Next Week" and "2 Hours".
Conversations and custom objects
Each option has a resource: conversation (the default) or kobject. Custom object options belong to one Klass, so when you create one, send resource: "kobject" with parentId (the Klass ID) or parentName (the Klass name). Lists return one resource type at a time, conversation unless you pass resource=kobject, and you can narrow custom object options with parentId or parentName. An option's resource and Klass can't be changed after creation.
The number of options is capped per resource type, and per Klass for custom objects, by your Kustomer plan. Creating an option past the cap fails with 400.
Why there are two sets of endpoints
The Core resources and Settings and configurations sections document the same /v1/snoozes endpoints, so both read and write the same list of options. Settings and configurations is the original, conversation-focused documentation, and it also lists the parentId and parentName filters. Core resources is the newer documentation: it adds custom object options, the resource field and the Klass lookup endpoint. Use either; the calls are interchangeable. Where the pages differ on how to target a Klass, send resource, parentId and parentName in the request body as described above.
Which endpoint to use
| To | Call |
|---|---|
| Build a snooze menu: list the options | GET /v1/snoozes (also documented here) |
| List options for one custom object Klass | GET /v1/snoozes/klass/{id}, or GET /v1/snoozes?resource=kobject&parentId={klassId} |
| Add an option | POST /v1/snoozes (also here) |
| Read one option | GET /v1/snoozes/{id} (also here) |
| Rename, retime, enable or disable an option | PUT /v1/snoozes/{id} (also here) |
| Remove an option | DELETE /v1/snoozes/{id} (also here) |
PUT changes only the fields you send (name, value, type or enabled), and DELETE removes the option permanently with 204. Any user who can read settings can list options; changing them needs admin or snooze write permission.
Path parameters
Snooze ID.
"6026aba3fcca5f03e5541cdb"Responses
OK