Verify your customers

Some workflows touch a customer’s own account, orders or bookings. Turn on Customer verifies their email first for those, and Dazza makes sure the customer is who they say they are before the workflow runs.

Email codes

If the customer isn’t verified, Dazza asks for their email in the chat and sends a six-digit code. They type it in and carry on.

• Codes expire after 10 minutes.
• A few wrong guesses and the code stops working.
• Sending is rate-limited per conversation and per address.

Once verified, the customer stays verified in that conversation for 12 hours, and the workflow uses their verified email.

Signed-in customers

If customers sign in to your site, your server can vouch for them, so they skip the code. Set it up in Settings → Install → Signed-in customers, which gives you a secret.

On your server, sign the customer’s details with the secret using HS256:

import jwt from "jsonwebtoken";

const token = jwt.sign(
  {
    email: user.email,
    name: user.name,
    sub: user.id,
    // Optional: details Dazza can use (see Customer details below)
    attributes: { plan: user.plan, account_number: user.accountNo },
  },
  process.env.DAZZA_SECRET,
  { algorithm: "HS256", expiresIn: "12h" }
);

Then pass the token to the chat, either on the script tag:

<script src="https://app.dazza.io/widget.js" data-agent="dz_…" data-user-token="TOKEN" async></script>

or from your page, which suits single-page apps:

Dazza.identify(token); // after sign-in
Dazza.identify(null);  // after sign-out

Google Tag Manager removes data-user-token from script tags. There, put the token in the settings the chat reads, with your key: window.DazzaSettings = { agent: "dz_…", userToken: "TOKEN" }, or use Dazza.identify(token).

Tokens must have an expiry, of up to 30 days. Keep the secret on your server; if it leaks, make a new one in Settings and old tokens stop working.

Customer details

The token can also carry attributes: simple facts from your own records, such as the customer’s plan, whether they’re a trade or retail customer, or their account number. Because they come in the signed token, Dazza can trust them.

• Up to 20 attributes. Names use letters, numbers and underscores, up to 40 characters, starting with a letter.
• Each value is text of up to 200 characters, a number, or true/false. Anything else (lists, nested objects) is left out, and the login still works.
• A token with attributes replaces the ones Dazza has for that customer. A token without them leaves them as they were, so older tokens keep working.

Dazza uses them in three places:

• Answers. Dazza gets them as background on the customer, so it can give the answer that applies to them, say the returns policy for trade customers, without reading them back.
• The inbox. They show beside the conversation, under From your sign-in.
• Workflow decisions. A decision can check them as Customer plan, Customer account number and so on, e.g. “If Customer plan is Business, tell them their account manager will quote within the hour.” They’re only there for a signed-in or verified customer; for anyone else they count as not given.

The REST API returns them on each contact, too.

Trusted senders

For email, when the sender’s domain vouches for them (the message passes DMARC) and they want replies to the same address, they count as verified.

What your system is told

When a workflow calls your system, the request includes the customer’s verified email and how they were verified. An email typed into the chat is never treated as proof.