We’ve got an outbound flow that needs to ping a customer who chatted with us last week. The setup requires pulling the old guest ID from the CRM first. Then we fire a REST Proxy call through Studio to drop a proactive message into their browser tab. The SNIPPET action looks standard enough. We’re hitting /api/v2/webchat/guests/{guestId}/notifications with a basic JSON body.
Step one, we map the guest ID into the URI. Step two, we attach the bearer token to the Authorization header. Step three, we POST the payload.
{
“sender”: { “id”: “sys_admin”, “type”: “system” },
“text”: “Your order shipped. Tap here to track it.”,
“templateId”: “tmpl_proactive_v1”
}
The request drops a 401 Unauthorized almost immediately. OAuth token generation works fine for the initial auth step, and the same bearer token pulls queue stats without issue. Something about the webchat guest endpoint rejects it. We’ve checked the role permissions on the integration user. It’s got full access to messaging and webchat. The guest session definitely closed, not terminated, so the ID should still be valid in the system.
Looking at the raw response headers, there’s a WWW-Authenticate challenge pointing to a stale token scope. The scope list includes webchat:guest:write but maybe it needs webchat:proactive:trigger instead. I can’t find that scope in the docs. The Studio flow hangs on the SNIPPET timeout after we retry with a fresh token. Is there a separate auth flow required for proactive pushes, or does the guest API expect a different header structure? We’re just trying to get the payload through without rebuilding the whole notification engine.