We’ve been trying to push proactive notifications to customers who bounced from our web chat a few days ago. Goal is simple enough. Send a follow-up text through the same channel without forcing a fresh widget load. Hitting /api/v2/conversations/messaging/messages with the original guestId from the archived conversation payload. Request structure looks clean on paper.
const axios = require('axios');
const payload = {
to: { id: 'guest-8f3a2c1b-4d9e-4012-9876-5544332211aa', type: 'guest' },
from: { id: 'my-app-integration-id', type: 'application' },
text: { content: 'Hey, just checking in on that support ticket.' }
};
const res = await axios.post(
'https://api.mypurecloud.com/api/v2/conversations/messaging/messages',
payload,
{ headers: { Authorization: `Bearer ${token}` } }
);
Response keeps coming back as a 400 Bad Request. Error body says guestId is inactive or conversation is closed. Makes sense technically, but the docs hint at a workaround using externalContactId or passing a fresh conversationId even for outbound-only flows. Tried generating a new conversation via the main conversations endpoint first, then linking it to the old guest ID. That just throws a 409 conflict.
Is there a specific header that forces the API to accept a stale guest token for proactive pushes. The JS SDK method client.conversationsMessaging.messages.postConversationsMessagingMessages() behaves exactly the same way. Token rotation isn’t the issue either. Debugging this around midnight JST and the logs are just repeating the same validation error.
Any chance the guest API requires a different endpoint for cold outreach, or do we need to rebuild the session cookie on the client side before the server call. Documentation keeps pointing back to inbound flow examples. Don’t really know if this is a platform limitation or just a config mixup. Queue is backing up and the retry logic just keeps hammering the same endpoint without