Setting up a webhook to post to Slack when a queue breaches SLA. Using the queue:member:activity:changed event type for now to test the flow, but ultimately need queue:sla:breached. The endpoint is a simple HTTP POST to a Slack Incoming Webhook URL.
Here is the payload template I’m using in the Genesys Cloud webhook configuration:
{
"channel": "#alerts",
"username": "GenesysBot",
"text": "SLA Breach: {{queue.name}} has been waiting for {{wait_time_seconds}}s. Current position: {{position_in_queue}}"
}
The issue is a 403 Forbidden response from Slack. The webhook URL is correct because I can curl it manually with a static payload and it works fine. Genesys returns a 200 OK on the webhook execution log, but Slack rejects it.
Checked the request headers. Genesys sends Content-Type: application/json. Slack expects that. Not sure if there’s an issue with how Genesys serializes the template or if I need to add specific headers in the webhook config. The logs show the raw request body looks malformed, missing the outer braces sometimes.
Tried changing the event to interaction:created and it works. Seems specific to queue events or maybe the template variables are causing JSON parsing errors on Slack’s side when the variables are null. Any ideas on how to debug the actual HTTP request Genesys sends?
Queue SLA breach events don’t fire on the standard webhook subscription list in the same way activity changes do. You’re likely hitting a scope mismatch or trying to subscribe to an event that requires specific org-level permissions.
- Check your OAuth scope. You need
webhooks:view and webhooks:edit, but for the event to trigger and be visible in the subscription list, the app or user creating the webhook needs routing:queue:view. If you’re using a service account, ensure it has the routing:queue:view scope.
- Verify the event type availability.
queue:sla:breached is a valid event, but it only fires if SLA is actually configured and breached for that specific queue. Test with queue:member:activity:changed first, then switch. If the 403 persists on the SLA event, it’s almost certainly a permission issue on the queue resource itself.
- Slack Incoming Webhooks are simple, but Genesys Cloud webhooks use basic auth if configured. If you left the username/password blank in Genesys, it sends no auth header. Slack doesn’t require it for incoming webhooks, but if you accidentally toggled “Use Basic Auth” in the Genesys webhook config, it’ll send
Authorization: Basic ... which Slack might reject if not expected. Leave auth fields empty for Slack.
- Try this minimal payload structure. Strip down the template to see if it’s a parsing error masquerading as a 403.
{
"channel": "#alerts",
"text": "SLA Breach detected in queue: {{queue.name}}"
}
If the webhook still fails, check the Genesys Cloud logs under Administration > Integrations > Webhooks. Click the webhook, go to the “History” tab. It’ll show the exact HTTP response from Slack. A 403 from Genesys Cloud means Genesys blocked it. A 403 from Slack means Slack blocked it. The log will tell you which one.