Setting up verified identity

Availability

Verified identity is part of the Customers beta. Find it at Audience → Customers → Identity settings.

The problem it solves

Your Customers list collects everyone who uses your public AppGram pages — the feedback board, roadmap, surveys, and status page. By default you only know what they choose to tell you: maybe an email they typed in, maybe nothing at all. An email like that could belong to anyone.

Verified identity closes that gap. Your own app's backend signs a short-lived token that says this really is our user, and AppGram marks that person Verified with their real id, plan, and attributes.

How it works

A one-time setup, then it runs automatically:

1. Copy the secret into your backend. Take the signing secret from Identity settings into your app's server environment. It never touches the browser.
2. Sign a token for each logged-in user. When one of your users opens your AppGram portal, your backend signs a short-lived token stating who they are.
3. AppGram verifies and enriches the record. AppGram checks the signature, then marks that person Verified in Customers — with their real id, plan, and attributes.

The project identity secret

Each project has its own HS256 signing key. Treat it exactly like a password:

• Keep it in server-side configuration or a secrets manager, never in client code or a public repository.
• Never ship it to the browser. If it reaches the frontend, anyone can mint tokens claiming to be any of your users.
• If you suspect it has leaked, rotate it from Identity settings.

Because signing depends on your stack, the step-by-step code — copy-paste examples, the full list of claims you can include, and how to pass the token into the AppGram SDK — lives in the developer documentation, linked from the Identity settings page.

What verification changes

Once someone is verified:

• Their record carries your external user id, so it lines up with your own database.
• The attributes you send — plan, seats, signup date, role, anything else — become filterable and available to automations and survey targeting.
• Support tickets from that person arrive with account context attached.

Verification is per person, not per project. A portal can hold verified, self-identified, and anonymous people at the same time, and that's expected — not everyone who reads your roadmap is logged into your app.

Choosing what to send

Send the attributes you intend to act on. Good candidates:

• Plan or tier — the single most useful field for routing and targeting.
• Seats or account size — for prioritizing.
• Signup date — for separating new users from long-time ones.
• Role — an admin's feature request usually means something different from a viewer's.

Avoid sending anything you wouldn't want visible to your own team in the dashboard, and don't send secrets or payment details.

Verifying it works

Open your portal while logged into your own app, then check the Customers directory. Your own record should appear with the Verified badge and the attributes you sent. If it shows as self-identified or anonymous instead, the token isn't reaching AppGram or isn't passing signature verification — check that the secret in your backend matches the one in Identity settings for that project.