Widget Identity
Widget identity connects a visitor to a stable customer record and conversation history.Modes
How Verification Is Enforced
Woes uses the same model as Intercom: verification protects identified users without locking out anonymous ones:- Anonymous visitors with no
identifycall, oridentifywith no email, can always chat as leads. Turning on verification never blocks them. - Identified visitors must carry a valid HMAC hash or JWT when they pass an email. An identity claim without a valid proof is rejected, so a browser user can never impersonate another account.
- Strict mode blocks anonymous visitors entirely. Turn on Require verified identity only when everyone must be verified before chatting.
Install Contract
Verified identity has a hard public/private split:
Your app should expose an authenticated, no-store endpoint, such as
/api/woes-identity, that returns the signed proof for the current logged-in user.
The browser should fetch that endpoint and call window.Woes("identify", ...):
- After login or session load.
- When
https://woes.dev/widget.jsfinishes loading. - On window focus.
- When the page becomes visible again.
identify repeatedly for the same current user is safe. Do not suppress retries for the same HMAC or JWT before Woes has accepted it; retries prevent boot-order races from leaving a logged-in customer anonymous.
The identity secret is private signing material. Keep it on your server only.
Do not paste it into client JavaScript, mobile apps, documentation, or AI
coding prompts.
Verify an Install
Use Settings → Security to confirm both halves of the integration:- Select the agent widget key installed on the site.
- Open the site page where the widget script is installed.
- In Woes, click Refresh in Install check. The site origin should appear
with a recent
last seentime. - Generate a real identity proof from your application backend.
- Paste the customer email and
email_hashfor HMAC mode, or paste the JWT for JWT mode, into Test an identity proof. - Click Verify proof before testing a live chat message.
trim().toLowerCase() before
signing.
HMAC Email
In HMAC mode, your backend signs the normalized customer email using the selected agent widget’s identity secret. The browser sends the email and hash to Woes. Only the normalized email is verified.name, company, and id remain display metadata. Use JWT when account or contact ids must be verified.
identify after your backend returns the proof and before the visitor sends
their first message. The widget asks Woes to verify the proof before it treats
the visitor as verified.
JWT
In JWT mode, your backend signs a token that includes the customer’s email and optional identity fields. Woes verifies the token before trusting the identity.HS256, include an email claim, and set aud to the widget public key used by the install snippet. Keep token lifetimes short; Woes accepts verified widget identity JWTs up to 15 minutes from issue to expiry.
Browser Integration Checklist
- Load
https://woes.dev/widget.jswith the selected public widget key indata-public-key. - Create or rely on the Woes command queue before calling
window.Woes(...). - Fetch your authenticated identity endpoint with same-origin credentials and no-store caching.
- Treat
401from the identity endpoint as anonymous mode unless strict verified identity is required. - Call
window.Woes("identify", identity)every time a valid signed identity is returned. - Verify a logged-in test visitor sends a message and appears in Woes with their email/name and
identity_sourceofwidget-token.
aud claim must exactly match the data-public-key in the installed widget
script.
Copy Prompt for AI Install
Settings → Security includes Copy prompt for AI install after you select an agent widget key. Paste that prompt into your coding assistant to install the widget and create the server endpoint that mints the HMAC hash or JWT. The copied prompt intentionally includes:- The public widget key for the selected agent.
- The selected verification mode.
- Server-only environment variable guidance.
- The authenticated no-store identity endpoint contract.
- The required browser
window.Woes("identify", ...)call and retry behavior.
- The private identity secret.
- Workspace API keys.
- Supabase or Stripe keys.
- Operator-only account data.
Security Rules
- Generate signatures server-side.
- Never expose identity secrets to the browser.
- Use stable customer identifiers.
- Do not include raw secrets in identity metadata.
- Confirm the widget install uses the correct workspace or agent key.
- Treat unsigned browser identity fields as untrusted metadata.
