Site Keys — MANDATE

Start in Observe on one route. Use the deployment URL and installed package version supplied for your workspace. Historical host examples and source capabilities do not establish a live service or published release.

Overview

Every MANDATE integration requires a site key pair: a public key for your frontend and a secret key for your backend.

Credential	Prefix	Visibility	Purpose
Site Key	`sk_live_` / `sk_test_` / `sk_staging_`	Public	Identifies your site when loading the gate script
Site Secret	`mss_live_` / `mss_test_` / `mss_staging_`	Private	Verifies tokens on your backend

Creating a Site Key

Go to the MANDATE Dashboard
Navigate to Integrations > Add app or use the Launchpad setup checklist
Enter a name (e.g., "Production", "Staging")
Add your allowed domains
Copy both the site key and site secret

Warning

The site secret is shown only once at creation time. Store it immediately in your secrets manager or environment variables.

Domain Allowlist

Each site key has a domain allowlist that restricts where the gate script can be loaded from. Requests from non-allowed domains are rejected with HTTP 403.

Configure allowed domains in Launchpad when adding an app or editing its setup checklist.

Code

example.com
*.example.com
staging.example.com
localhost:3000

Info

Wildcard subdomains (*.example.com) match any subdomain but not the apex domain itself. Add both example.com and *.example.com to cover all cases.

Multiple Environments

Create separate site keys for each environment:

Environment	Site Key	Domains
Production	`sk_live_...`	`example.com`, `*.example.com`
Staging	`sk_staging_...`	`staging.example.com`
Development	`sk_test_...`	`localhost:3000`, `localhost:8080`

This allows you to:

Track scores and traffic separately per environment
Apply different action thresholds per environment
Disable development keys without affecting production

Environment Variables

Store your credentials as environment variables:

bash

# Frontend (public — safe to expose)
NEXT_PUBLIC_MANDATE_SITE_KEY=sk_live_...

# Backend (private — never expose)
MANDATE_SITE_SECRET=mss_live_...
MANDATE_SITE_KEY=sk_live_...
# During an explicit rotation overlap only:
# MANDATE_PREVIOUS_SITE_SECRET=mss_live_previous_...

Node local verification reads current and optional previous secrets without calling MANDATE. After you retire the previous version, remove MANDATE_PREVIOUS_SITE_SECRET and redeploy.

Rotating Secrets

To rotate a site secret:

Go to Integrations > Site keys
Click Rotate
A new secret is generated. The old secret remains valid during an explicit overlap
Update your backend environment variable with the new secret
After deploying, click Retire previous to stop accepting the old secret

Tip

Overlap has no automatic timer. Both secrets remain valid until you explicitly retire the previous version or perform another rotation. For a compromised secret, use emergency replacement instead of overlap.

If the new secret causes a deployment failure, use Rollback before retiring the previous version. Rollback restores the previous secret as current and revokes the failed new version. Emergency replace instead revokes every older version immediately and returns one new show-once secret.

Revoking a Site Key

Revoked site keys immediately reject all requests. The gate script returns HTTP 403 and no tokens are issued.

To revoke: go to Integrations > Site keys and click Revoke.

This is useful for:

Revoking compromised keys
Decommissioning old environments
Emergency incident response