Skip to main content
You can tell the widget who the current shopper is, using either of two trust levels that work independently.

Identify

Tell Remark the shopper’s email, phone, or name.

Verify

Verify the shopper’s identity with a signed token.
You call both through window.remark(...), which loads asynchronously, so your code needs to wait until it’s ready before calling it. The examples below do that with the whenRemarkReady helper from Waiting for Remark to initialize.

Identify (unverified)

Use identify to tell Remark who the shopper might be, so it can greet them by name or attach the conversation to a known shopper.

Fields

Every field is optional, but provide at least an email or phone for the shopper to count as identified.
Because identify details come from the browser, anyone could claim any email. Use them for personalization only, not to gate order history, account details, or other sensitive data. Use Verify for that.

Verify (trusted)

Verify proves a shopper is who they say they are, so Remark can show order history, account details, or act on their behalf. Your server creates a short, signed token naming the shopper, and Remark checks the signature before it trusts the token. The one rule is to keep that signing secret on your server and out of the browser: as long as it stays there, no one can forge a token. Remark holds its own copy so it can check the signature.

1. Get your signing secret

In the Remark dashboard, go to Settings → Identity verification and select Generate secret. Remark shows it only once, so copy it and store it somewhere only your server can read, such as an environment variable, and never in client-side code. To replace a secret later, use Regenerate. The new secret works right away, and any token signed with the old one stops working, so regenerate when traffic is low.

2. Sign a token on your server

When you render a page for a signed-in shopper, create a short-lived JSON Web Token signed with that secret. The token must:
  • use the HS256 algorithm,
  • include the shopper’s email, phone, or both,
  • set sub to the shopper’s lead, so the token only works for that shopper’s session,
  • set an expiry (exp) about 5 minutes out. Remark rejects tokens that last much longer than that.
The sub claim is what ties the token to one shopper. Remark gives every visitor a lead and stores it in the remark_lead cookie on your domain, so it rides along with the request above. If your token endpoint can’t read that cookie, read the lead in the browser from localStorage under remark_lead and send it to your server. Unlike the email and phone, the lead is not sensitive, so reading it from the browser is fine: it only scopes the token to this session.
Build the token for the shopper who is signed in to your server. Read their email or phone from your server-side session, never from a query parameter, form field, or anything else the browser sends. Otherwise someone could request a token that claims to be another shopper.

3. Verify from the page

Fetch a fresh token from your server when the page loads, then pass it to Remark:
Sign a fresh token on each page load rather than storing one and reusing it.

Confirming it worked

If the token checks out, Remark records the shopper’s email and phone as verified. If a token is invalid, expired, or set to last too long, Remark rejects it. The page doesn’t get an error back, and nothing prints to the browser console unless the request itself fails. To confirm your tokens are being accepted, open Settings → Identity verification in the dashboard. The signing secret shows when it was last used: after a verified shopper loads a page, the badge changes from Never used to a recent time.

Signing out

When the shopper signs out of your site, tell Remark to drop their verified status:
Call this from your sign-out handler. It works whether or not the shopper ever verified, so you don’t have to track that yourself.

Token reference

Remark normalizes the email and phone, so send real, well-formed values.