Docs state: “To send a message to a participant, you must first establish a conversation by sending a POST request to the /api/v2/conversations/messaging/addresses endpoint.”
I’m trying to push a proactive notification to a customer who chatted with us yesterday. We have their externalId and the previous conversationId. The goal is to resume that session rather than starting a new one.
I’m using the Client Credentials grant to get an access token. The token is valid. I can fetch user details just fine. But when I hit the messaging endpoint, I get a 403.
Here is the payload I’m sending:
{
"to": [
{
"address": {
"id": "cust-12345",
"externalId": "cust-12345",
"type": "email"
}
}
],
"from": {
"address": {
"id": "agent-bot-01",
"type": "email"
}
},
"text": "We have an update regarding your previous inquiry."
}
The response is:
{
"code": "forbidden",
"message": "User does not have permission to perform this action."
}
I’ve checked the scopes on the OAuth client. It has messaging:conversation:write and messaging:address:write.
Is there a specific scope required for resuming an existing conversation? Or do I need to use the conversationId in the POST body? The docs don’t show a conversationId field in the request schema for /addresses.
You can’t use Client Credentials for this. That grant type is for server-to-server tasks, not impersonating users or acting on behalf of specific agents/customers in a conversation context. The 403 is expected because the token lacks the identity context required for messaging actions.
You need to switch to Authorization Code grant with PKCE or use a User Context token. If you’re doing this from a .NET backend, generate a user-scoped token first. Here’s how I handle it in Azure Functions:
var authConfig = new OAuthConfig("yourClientId", "yourClientSecret", "yourLoginUrl");
// Use the user's OAuth token here, not client credentials
var client = PlatformClientFactory.CreateClient(authConfig, new AuthorizationCodeConfig());
client.SetAccessToken(userAccessToken);
Also, check if the conversation is actually closed or terminated. You can’t resume a terminated session. Use GET /api/v2/conversations/messaging/{conversationId} to verify the status before attempting to send. The docs are vague on the exact lifecycle states allowed for resumption.
The point above is correct about the grant type, but you’re also hitting a scope wall. Just switching to Authorization Code won’t fix the 403 if your app registration doesn’t have messaging:conversation:write or messaging:participant:write. Client Credentials tokens are strictly for system-level operations like creating integrations or fetching analytics. They don’t carry the agent identity needed to touch a conversation thread.
If you’re building a custom DFO channel or a bot that needs to resume a session, you’ll want to use the messaging:conversation:write scope. Here’s a quick curl example to verify your scopes are actually attached to the token before you even hit the API:
curl -X POST "https://api.mypurecloud.com/api/v2/oauth/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=authorization_code&code=<AUTH_CODE>&client_id=<YOUR_CLIENT_ID>&client_secret=<YOUR_CLIENT_SECRET>&redirect_uri=<YOUR_REDIRECT_URI>"
Check the scope field in the response. If messaging:conversation:write isn’t there, you’re dead in the water. Also, make sure you’re posting to the specific conversation ID, not just the addresses endpoint blindly. The 403 usually means the token is valid but the resource access is denied due to missing scopes or insufficient role permissions on the user profile generating that token.