Visitor identity
Link a widget visitor to an account on your website and verify their external ID with a signature.
Main section: Initialization Parameters.
Visitor Data
user contains the data Senler uses to create or update the widget lead. Pass only information about the current visitor that your data-processing policy allows.
| Field | What to pass and how it is used |
|---|---|
external_id | A stable authenticated-user ID from your system. When it is present, user_hash is required. |
user_hash | An HMAC-SHA256 signature of external_id, calculated by the site backend with the channel secret and encoded as 64 hexadecimal characters. |
email | The lead email. A non-empty value is saved on creation and updates an existing lead. |
phone | The loader and API accept a string but do not save it to the lead profile. |
first_name, last_name | The lead's first and last name. Non-empty values are saved on creation and update. |
avatar_url | A public HTTPS URL without embedded credentials. An explicitly passed empty, invalid, or local value means no avatar and removes the existing lead's previously saved avatar. |
data | A plain JSON-compatible object with additional data. On repeat initialization, a non-empty object is shallow-merged into saved data; omitted keys are not deleted. |
Signing the external ID
Always pass external_id together with user_hash: initialization is rejected without the signature. The cabinet identity-linking switch adds these fields to generated code and exposes the secret and backend examples; it does not enable or disable the verification itself. Never put the secret in HTML, loader configuration, or any other browser code. Linking to an Authorized User shows the complete setup.
For example, a Node.js backend signs the exact external_id value as follows:
import { createHmac } from "node:crypto";
const userHash = createHmac("sha256", channelSecret)
.update(externalId)
.digest("hex");
Send only the externalId and resulting userHash values to the browser as external_id and user_hash. Keep channelSecret on the server.
History and service access
With a signed identity link, history belongs to the same account across devices. Without external_id, Senler creates an anonymous browser session, so previous history is unavailable after switching browser or device.
To avoid assembling user manually, open Code building example in the channel settings. That illustrated guide shows how to select fields, add pairs to user.data, and copy the example. The builder demonstrates the accepted data shape but does not change the channel's primary code.
The user_hash signature verifies the visitor’s identity; the agent’s access to an external service is configured separately. For an installed MCP with per-lead authorization, the backend can save the user token in advance using POST /api/mcp-servers/external-user-credentials. See website user authorization for MCP for the complete sequence, parameters, renewal, and revocation.