Get started

If a Secret Key leaks, open the project in the dashboard and use Rotate Keys. Rotation replaces both keys of that project at once; the old pair stops working immediately, so update your frontend data-site-key and your server environment variable together.

Both methods target the same account, keyed by your email address. Signing in with Google for the first time on an existing, verified password account automatically connects Google to it; your password keeps working. You can also connect Google from dashboard account. The Google account's email must match your TrustSig email exactly.

TrustSig 2FA (authenticator app or email codes) applies to every sign-in, including Google. If 2FA is enabled, a Google sign-in is challenged for a code exactly like a password sign-in; connecting Google does not weaken or bypass it.

Our recommendation: if you sign in with Google only, your account security equals your Google account security. Keep 2FA enabled on your Google account and you do not need a separate TrustSig password or TrustSig 2FA. We do not recommend adding a password you will not use; a second credential is a second thing to phish. If you do use a password (alone or alongside Google), enable TrustSig 2FA with it.

Every account has a personal organization that owns its projects and subscription. Inviting members shares that organization; granting a member the Owner role gives them full permissions, but the organization itself, including billing, remains anchored to the founding account.

To hand an organization over for real, use Transfer ownership on the team page. Projects, members, pending invites, the subscription, and billing history move to the new owner; you stay on as an admin. Requirements: the new owner is an accepted member with a verified email, and their own personal organization is empty (no projects, members, or paid plan).

Deleting your account permanently removes your personal organization: its projects, their verification data, and your subscription (any paid plan is cancelled at Stripe). This cannot be undone.

Organizations you were invited to are not affected, whatever your role there. You are removed from their member lists; their projects, members, and billing continue unchanged. If your own organization still has members, you must remove them (or transfer ownership) before deletion is allowed.

A project maps to one application, not one hostname. If the same application is served from several hostnames (production, staging, a country domain), keep them in one project and add each hostname to its Allowed Domains list. All of them share the project's keys and report into the same stats.

Create separate projects for separate applications, or whenever you want isolation: separate keys (rotating one project's keys does not touch the others), separate traffic stats, and a separate Troubleshoot log per project.

Your plan sets two account-wide limits: how many projects you can create, and how many domains you can register in total across all projects. Both meters are shown on the projects page in the dashboard. Monthly request volume is a third, separate limit; see Usage & Quotas.

The edge only issues tokens to origins on the project's Allowed Domains list. Requests from any other origin are rejected and logged as NON_WHITELISTED_DOMAIN in the project's Troubleshoot log. Add every production and staging hostname you serve the SDK from.

Local development hosts are auto-allowed. You do not need to add them to your project. The following origins always pass the allow-list check:

• localhost and IPv6 loopback (::1, [::1])
• Link-local: IPv4 169.254.0.0/16, IPv6 fe80::/10
• RFC 1918 private IPv4: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• Any hostname ending in .localhost, .local, or .test

So localhost:3000, 127.0.0.1, 192.168.1.42, mac-mini.local, and app.test all work during development without any dashboard changes. Production domains must still be added explicitly.

When the edge rejects a client, the rejection surfaces in the project's Troubleshoot log in the dashboard with one of these codes:

One client-side scan is one request. A scan is the SDK fingerprinting the browser and fetching a token from the edge. Server-side verification of that token is free: checking tokens never consumes quota, only issuing them does.

Current prices and any plan changes live on the pricing page; your account's live limits are always shown in dashboard billing.

On paid plans, protection continues past the included volume as metered overage at €5 per 100,000 extra requests, up to the plan's overage allowance. An overage protection threshold in dashboard billing caps your exposure: if the unpaid overage balance exceeds the threshold you set (at most €100), service pauses until it is settled. One-time top-ups are also available if you prefer prepaid volume over metered overage.

Starter has no overage allowance. If you regularly exceed the included volume, upgrade the plan or reduce what you scan (below).

The dashboard overview shows the live monthly usage meter against your plan limit. Billing holds the usage history, the overage ledger, and invoices.

If only specific actions need protection, disable the automatic page-view scan with data-auto-scan="false" and trigger scans manually via the JavaScript API on the submits and logins you actually verify. You then spend exactly one request per protected action instead of one per page view.

If your site sends a Content-Security-Policy header, the browser blocks the SDK unless the TrustSig edge origin is allowed in three directives. Without them the script fails to load, no token is issued, and every protected request arrives without a trustsig-response.

Appended to an existing policy, the header looks like this:

script-src 'self' https://edge.trustsig.eu; frame-src https://edge.trustsig.eu; connect-src 'self' https://edge.trustsig.eu

Listen for trustsig:ready on window to know when the initial token scan completes.

window.addEventListener('trustsig:ready', (e) => {
  const { token, error } = e.detail;
  if (token) {
    document.getElementById('submit-btn').disabled = false;
  } else {
    // Fail-open: allow the action even if the scan failed
    console.warn('TrustSig scan failed:', error);
  }
});

Use window.TrustSig.getResponse() for AJAX forms. Awaits any in-progress scan or returns the cached token immediately.

async function submitForm() {
  const data = await window.TrustSig.getResponse();
  const token = data?.token ?? null;

  await fetch('/api/login', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-TrustSig-Response': token,
    },
    body: JSON.stringify({ email: 'user@example.com' }),
  });
}

Use window.TrustSig.scan({ key }) when the SDK is loaded without a data-site-key attribute, for example multi-tenant apps that resolve the key at runtime, or pages that conditionally protect only some actions. The call runs a fresh hardware-fingerprint scan against the supplied key and resolves with a token.

async function submitForm() {
  const result = await window.TrustSig.scan({
    key: 'pk_live_3426256ed11ff6e0f55af31c8328afe5',
  });
  const token = result?.token ?? null;

  await fetch('/api/login', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-TrustSig-Response': token,
    },
    body: JSON.stringify({ email: 'user@example.com' }),
  });
}

If your site sends a Content-Security-Policy header, the browser blocks the SDK unless the TrustSig edge origin is allowed in three directives. Without them the script fails to load, no token is issued, and every protected request arrives without a trustsig-response.

Appended to an existing policy, the header looks like this:

script-src 'self' https://edge.trustsig.eu; frame-src https://edge.trustsig.eu; connect-src 'self' https://edge.trustsig.eu

Wrap your app (or the subtree that needs protection) with TrustSigProvider.

"use client";
import { TrustSigProvider } from '@trustsig/react';

export default function RootLayout({ children }) {
  return (
    <TrustSigProvider siteKey="pk_live_..." autoScan={true}>
      {children}
    </TrustSigProvider>
  );
}

When verification fails, BotAnalysisResponse carries one of these in error (and mirrors it in factors):

verifyLocal tracks the SHA-256 hash of each accepted token in process memory and caps reuse at 4 calls per token by default. The 5th call resolves to BLOCK with error: 'TOKEN_REUSED'. Cache entries auto-evict at issued_at + maxTokenAgeSeconds (default 300s), so memory stays bounded by the in-flight token set. Fail-closed contract is unchanged; never throws, always returns a BotAnalysisResponse.

TrustSigErrorCode now includes 'TOKEN_REUSED':

TOKEN_MISSING | TOKEN_EXPIRED | TOKEN_REUSED | CRYPTO_FAIL | API_FAIL | MALFORMED_RESPONSE

result.factors also includes 'TOKEN_REUSED', so existing log and grouping pipelines pick it up automatically. The allow-list gate stays the same; if (result.action !== 'ALLOW') deny() already covers it.

// Defaults: replayProtection on, 4 uses per token.
const ts = new TrustSig({ secretKey });

// Single-use tokens (checkout confirmation, OTP, password change).
const oneShot = new TrustSig({ secretKey, maxUsesPerToken: 1 });

// Keep tracking but raise the cap.
const generous = new TrustSig({ secretKey, maxUsesPerToken: 50 });

// Off: accept the same token unlimited times within its age window.
const noReplay = new TrustSig({ secretKey, replayProtection: false });

// Manual reset (tests / operator action).
ts.clearReplayCache();