Identifying visitors and passing metadata in Live Chat

Visitor identity

By default, visitors are anonymous with a session ID persisted in localStorage. To attach a known user you have two options:

• Pre-identify at init — pass userId, email, and/or name directly in the init() call. This is the recommended approach when using Google Tag Manager or server-rendered pages where the user is already known at page load.

• Identify after login — call Inquiru("identify", { userId, email, name }) any time after the widget initialises — for example, once your own login flow completes.

Either way, the identity is stored on the conversation and shown in the Live Chat inbox and Conversations page. Values of undefined or null (including the string "undefined" returned by GTM when a variable is unset) are automatically ignored, so unrecognised visitors are safely treated as anonymous.

Passing custom metadata

You can attach arbitrary key-value metadata to a session via the metadata object in init():

Inquiru('init', { widgetId: 'your-widget-id', userId: '{{cookie - User ID}}', email: '{{cookie - User Email}}', metadata: { api_key: '{{cookie - API Key}}' } });

Metadata values are stored on the conversation and made available as template variables in API Skill headers and body templates using the syntax {metadata.key_name} — for example, setting a header X-API-Key: {metadata.api_key} will be substituted with the visitor's actual key at call time. This lets you call per-user authenticated APIs without storing credentials server-side.

Passing Custom Fields

If you've created Custom Fields for your Helpdesk, you can set their values straight from the widget embed using the customFields object in init() — match the field's exact name (not case-sensitive) to the key:

Inquiru('init', {
  widgetId: 'your-widget-id',
  userId:   '{{cookie - User ID}}',
  customFields: { 'Customer ID': '{{dlv - customerId}}' }
});

This is the same pattern Google Tag Manager users already use for userId/metadata — reference any GTM variable (a data layer variable, cookie, etc.) as the value. Each value is validated against the field's type on arrival: a Dropdown field only accepts one of its configured options, a Number field must parse as a number, and a Checkbox field accepts "true"/"false". Values are written to the ticket if the field is Per Ticket scoped, or to the customer record (matched by identified email) if it's Per Customer scoped — visible in the ticket sidebar and on the Customers page either way. An unrecognised field name or an invalid value (e.g. a Dropdown value that isn't one of its options) is silently ignored rather than blocking widget init, so double-check the field name matches exactly if a value doesn't appear.