Programmatically Set Custom Conversation Attributes via Messenger Widget
There is currently no reliable way to programmatically set custom conversation attributes (CvDAs) via the Featurebase Messenger widget.
Even when attributes are correctly defined (case-sensitive keys, valid types), values passed at boot time do not appear in the Inbox conversation attributes.
Teams want to attach contextual, per-conversation metadata (e.g., current page URL, product area, flow context) at the moment a conversation is started.
Today, the only workaround is using user-level attributes, which is insufficient for session- or page-specific context.
Add support to programmatically set and persist conversation-level custom attributes via the Messenger widget (e.g., through boot or a dedicated API), with clear documentation and examples.
This would enable better routing, debugging, and contextual support workflows.
- Post type
- ✨ Other
- What part of Help Desk?
Log in to comment and vote
Comments1
Andrew
Aug 31
We're a mobile app (iOS and Android) and we've built our support flow so that the large majority of queries — realistically around 98% — are resolved by workflows alone, with no human and no AI agent involved. We know our customer base well enough to predict what people ask.
The catch is that most of those answers are platform-specific. Someone messages asking for a refund: the instructions for requesting one from the App Store and from Google Play are completely different, and the workflow can only send the right ones if it knows which platform they're on. Same story for cancelling a subscription, or restoring a purchase. So the workflow needs the field, and it needs it on the very first message.
What we're doing in the meantime: set the values as user attributes on boot, subscribe to
conversation.user.created, then copy them onto the conversation withPATCH /v2/conversations/{id}.That's fine for the agent view, but it can't drive automation. The workflow evaluates the moment the conversation is created and our webhook lands after that, so the conversation attributes may not be populated yet when the branch is taken. Which forces our automations to branch on user attributes instead — and those are last-write-wins, so a customer who opens the messenger on a second device overwrites them, and a workflow can end up reading the wrong platform for the conversation it's handling.
Being able to pass conversation attributes on
boot, stamped onto any new conversation from that session and available to workflows at evaluation time, would remove the webhook, the copy, and the ambiguity in one go.From the outside it also looks like a fairly small piece of work: the SDK already forwards arbitrary extra keys from
bootto your servers, and the API already supports conversation custom attributes. Both halves exist — what's missing is the wire between them. Happy to test it if you build it.