Trying to wire up a simple Slack notification for when a queue breaches its SLA. I’ve got the webhook endpoint hitting our internal lambda, which then posts to Slack. The trigger is set to queue.waiting.agents with a threshold. The issue is the payload. I’m expecting the queue_name in the event data, but it’s coming through as null or empty. I have to do a separate API call just to resolve the ID to a name, which is annoying.
Here’s the relevant snippet from the webhook payload I’m receiving:
{
"id": "queue-123",
"type": "queue",
"event": "queue.waiting.agents",
"data": {
"waitCount": 5,
"threshold": 3
}
}
Is there a flag I’m missing on the webhook configuration? Or do I need to subscribe to a different event type that includes the full queue object? The docs are vague on what exactly gets included in the data payload for events. I’ve tried toggling the “Include additional data” checkbox in the admin UI, but it doesn’t seem to change anything. Just want the name in the initial hit.
You’re hitting a known quirk with the queue.waiting.agents event. The payload schema is pretty skeletal by design to keep latency down, so it often omits the full queue object and just passes the ID. Doing a secondary API call is annoying, but it’s the reliable way if you stick with that specific trigger.
However, if you can tolerate a slight increase in event volume, switching to .queue.stats usually gives you a richer payload. The interval field contains the queue object with the name included. Just make sure your webhook endpoint can handle the higher frequency.
Here’s what the relevant part of the .queue.stats payload looks like:
{
"interval": [
{
"queue": {
"id": "abc123",
"name": "Support Level 1"
},
"waiting": {
"count": 5
}
}
]
}
Check the event definition in the developer portal. If you absolutely need the queue.waiting.agents trigger, you might have to cache the queue names locally in your lambda to avoid the API call every time. It’s a pain, but it works.
The .queue.stats suggestion is solid, but if you’re dead set on sticking with the queue.waiting.agents trigger to keep payload volume low, you don’t necessarily need to fire off a separate HTTP call for every single event. That’ll kill your throughput.
Since you’re using Node.js, just cache the queue map locally. Spin up a quick interval that hits GET /api/v2/queues every 5-10 minutes (or however often your queue config changes) and store the ID-to-name mapping in a Map or simple object. Then, when the webhook hits your Lambda, do a synchronous lookup. It’s a tiny bit of memory overhead for a massive latency win.
Here’s a rough sketch of what that looks like in your handler:
let queueCache = {}; // Populate this via a cron or startup fetch
exports.handler = async (event) => {
const queueId = event.body.queue_id;
const queueName = queueCache[queueId] || 'Unknown Queue';
// Post to Slack with queueName
await postToSlack(`SLA Breach: ${queueName}`);
};
Just make sure your cache refresh logic handles the 401 if the token expires.