Messaging metadata variables get their values from the signed JSON Web Tokens (JWTs) used for messaging authentication. During a conversation, a messaging AI agent can use this data to customize its responses, display information specific to the customer, or branch the conversation's flow.
For a broader overview of the AI agent variables and how you can use them in answers, see Using variables to personalize AI agent answers.
Enabling messaging metadata variables
Messaging metadata variables aren't enabled by default. To enable messaging metadata variables, an admin must create a signing key used to generate JWTs for messaging authentication. Messaging authentication and messaging metadata variables are only available for the Web Widget and mobile SDK channels.
For more information about setting up messaging authentication, see Authenticating end users in messaging for the Web Widget and mobile SDK.
Supported messaging metadata variables
Messaging metadata variable name | Description |
---|---|
Provided email | Email address of the customer. This email address is pulled from the JWT used for messaging authentication. |
Provided name | Name of the customer. This name is pulled from the JWT used for messaging authentication. |
Authenticated external ID | Unique alphanumeric string that identifies the customer. This ID is pulled from the JWT used for messaging authentication. |
Authenticated status | If true, the customer is authenticated. Otherwise,
false. This variable is always true or false, never empty.
When using the Authenticated status variable in a Branch by condition step, only the Is operator is supported. |
Using the Provided name and Provided email variables
Keep the following considerations in mind when using the Provided name and Provided email variables:
- Messaging AI agents automatically skip the collection of the Name and Email
variables for authenticated customers in an Ask for
details step. For authenticated customers, these
variables are empty and are skipped in later steps of the
conversation. Instead, use the Provided name and
Provided email variables.
Skipped Name and Email variable collection the from Ask for details step Provided name and Provided email variables - The JWTs used for messaging authentication don't require a customer's name
or email address. If your organization doesn't include a name or email
address in its JWTs, the respective
Provided name
and
Provided email
variable are empty and skipped during a
conversation.
In such cases, we recommend updating your JWTs to include a name and email address.
- The Provided name and Provided email variables are empty for unauthenticated customers. Avoid using these variables in answer steps for unauthenticated customers.
Using messaging metadata variables with unauthenticated customers
If a customer isn't authenticated, the Authenticated status variable's value is false. Other messaging metadata variables are empty for unauthenticated customers and are skipped during a conversation.
Best practices for using messaging metadata variables
When creating an answer that uses messaging metadata variables, keep the following best practices in mind:
- If you don’t include the customer's name or email address in the JWTs used for messaging authentication, don’t use the Provided name and Provided email variables.
- To build an answer flow that’s available to both authenticated and unauthenticated customers, use a Branch by condition step to check the customer's Authenticated Status variables. Only include messaging metadata variables in branches where Authenticated Status is true.
- If you’re building an answer that’s only available to authenticated customers and your organization's JWTs include a name and email address, use the Provided name and Provided email variables for the customer's name and email address. In such cases, you don’t need to collect this information again using an Ask for details step.
8 comments
Ryan Nally
In our app we've implemented a JWT using signing key and the login method outline in the sdk doc. I can see this call returning with a 200 status. Yet in our chatbot flow the Authenticated Status is not equating to true. Any suggestions on why this might be the case?
0
Afabio Junior
I've created a ticket on your behalf so we can investigate your issue further. Please check your email for more information. Thanks! And, speak soon!
-1
Maurice Baez
Hello,
I am a developer at a company that wants to integrate a zendesk bot into our application (we currently use another bot service provider and would like migrate away from them) - We need the ability to send an access token(to our api), along with other customer specific information (about 15-20 data points), in order to allow the bot to make api calls and respond with client specific information. The second paragraph of this document seems to indicate this may be possible here, however, it seems like Provided email, Provided name, Authenticated external ID, and Authenticated status are the only data points that can be sent, stored, and used, is that correct? I found the doc describing how to to use the identity function to send a jwt from our end, my assumption was that I'd be able to include which ever data points I needed on that jwt to be used by the bot, but maybe that's not the case? Thank you.
0
Rafa D.
Hi,
We give support to various websites, some of them share users registered with the same email.
Each one has a different widget but we noticed that all of them show all the history conversations, whetever the website, if the user email it's the same.
How can filter the conversations by brand?
0
Hiedi Kysther
Hi Maurice Baez
I've created a ticket on your behalf so our Support team can assist you further on your concern. Kindly check your email for more information. Thanks!
-1
Maxime Wozny
Once you are authenticated (with JWT) within the messaging widget, are you considered authenticated on the Zendesk Guide Help Center too ?
My use case : Our bot answers to authenticated clients, displaying them restricted articles (only visible to users that are authenticated in Zendesk Guide). If the user does not find anything useful, we ask details to create a ticket. Currently we manage to have the ticket, but not display the restricted article (it redirects to the authentication page of Guide).
0
Rupert Aranda
Hello, I am trying to enable authentication with our messenger chat. I am passing the jwt to `webWidget.authenticate.chat`, however Zendesk is still not recognizing the authorized user. I am using the `metadata` to check the status and external ID, but these come back as false and null. Any suggestions?
0
Rositsa Pavlova
I have the same issue as Rafa D., where we use number of different brands and we wish the customers to be able to see conversations history only with the associated Brand.
I was wondering if anyone has any work around this?
I think the best approach would be creating some sort of Master_ID, which may include couple of External_ID, based on each brand and emails used by the customer.
Best regards,
Rose
0