Personalization and identity
Overview
Use Messaging metadata to personalize conversations. Use identity tokens when the conversation must belong to a verified signed-in user.
Limitations
Messaging metadata is not proof of identity. Do not authorize access to an account from a browser-supplied email address or identifier alone.
The SDK accepts up to 50 custom metadata fields. Keys have a 256-character limit; string values have a 1,024-character limit.
Nested objects and arrays are discarded. See the metadata differences before migrating complex payloads.
Capabilities & configuration
Choose the correct Messaging mechanism for the data you need.
Identity tokens are short-lived and single-use. Mint a new token for each device, sign-in, or exchange attempt.
Implementation & usage
Coordinate Messaging identity with the team that owns your application’s authentication.
To plan an identified integration:
- Have your backend create or find the end-user record with the End Users API.
- Mint an identity token on the backend for that
end_user_id. - Pass the token through the SDK’s documented identity configuration.
- Handle identity errors explicitly in your application.
- Test reset, sign-out, account switching, and a second device.
The SDK can continue anonymously after an identity-token error. Treat authenticated access as a separate application requirement.
Follow Identity getting started for the complete flow. Keep API keys on your backend.
The Conversations API’s custom-channel creation flow is separate from a native SDK session. Use the SDK to open the Messaging conversation.
Related features
Review Data controls and the identity lifecycle rules with your implementation.