Manage saved settings
In the Console, open team or project Settings → Embedded Signup. You can enable the widget, select connection modes and methods, allow exact redirect URLs and embed origins, and configure its name, colors, shape, theme, watermark, and history-sync behavior. Server automation can read the effective settings withGET /v1/widget and
save changes with PUT /v1/widget. Send projectId to manage settings for one
project; omit it to manage the organization defaults. These Platform API
operations accept an organization key with widget permission or a signed-in
Console bearer. They reject project and client tokens.
PUT /v1/widget accepts any subset of these fields:
Use HTTPS redirect URLs and origins. Origins must contain only the scheme and
host. Stored settings take precedence over protected per-session values when
you create a widget session.
Create a widget session
CallPOST /api/widget/sessions from your backend with an organization key
that has widget:create. Widget creation is a human-controlled operation;
project tokens are rejected even when they carry similarly named scopes.
Request fields
Project configuration controls whether the widget is enabled, allowed modes, redirect URIs, origins, branding, shape, watermark, connection methods, and history-sync behavior. Protected stored settings take precedence over request values.
Embed the returned URL
Use the returnedwidgetUrl directly in an iframe, or load the helper served by the API:
titan:widget postMessage events and supports connected, error, and cancelled. The global Titan.createWidget({ url, container, onConnected, onError, onCancelled }) compatibility API provides programmatic mounting.
Redirect flow
Setmode to redirect, supply an allowlisted callbackUrl, and send the browser to redirectUrl. Redirects are closed by default until exact callback URLs are configured for the project.
Cancel a pending session
DELETE /api/widget/sessions/{session} revokes the widget rules and cancels a pending connection.
Cross-device handoff
A widget client token for the same session can callPOST /api/widget/sessions/{session}/handoff. The response contains a handoffUrl, an SVG meta-QR, and expiresAt. The receiving device opens the URL and polls GET /widget/handoff/{token}/state for the current WhatsApp QR and session status.
The handoff token is the bearer credential and expires within 15 minutes. The
handoff becomes unusable after it is consumed or invalidated; a copied token
remains sensitive until it expires. State responses use
Cache-Control: no-store so browsers and shared caches do not retain the QR or
session status.
Treat the token like the widget URL and never log it.
Security model
- The organization key remains on your server; project tokens cannot create widget sessions.
- The browser receives a session-bound
titan_ct_token with widget-only actions. - Redirect URLs and embed origins are checked against project settings.
- Handoff state uses a short-lived signed token in the URL; no credential exchange occurs on the second device.
- Cancelling a session revokes its client-token rules.
Where to go next
Client tokens
Learn how browser-safe credentials are constrained.
Webhooks
Observe the resulting session lifecycle.