Server token (anti-replay)

For high-value flows, the backend pre-issues a short-lived token bound to the user's IP at issuance time. The verification token returned to the SDK is then bound to that session — a leaked token can't be reused by another user. View source.

Live demo

The page calls /issue-token.php first, then mounts the widget with the issued token.

Loading…

View HTML source Backend issue-token.php Backend verify.php

Integration flow

// 1. On page load, your backend issues a fresh token.
//    POST https://apiv1.captcha.la/v1/server-token/issue (server-side)
//    Body: { action, binding_ip, ttl: 300, max_uses: 10 }

// 2. Frontend fetches the issued token via your endpoint.
const res = await fetch('/issue-token.php?action=register');
const { token: serverToken, app_key } = await res.json();

// 3. Mount the widget with the server token bound in.
Captchala.init({
  appKey: app_key,
  serverToken: serverToken,    // ← bound to user's IP, expires in 5 min
  product: 'popup',
  bindTo: '#signup-btn',
  action: 'register',
  onSuccess: (res) => {
    // 4. Backend verifies the verification token (still required).
    fetch('/verify.php', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ token: res.token, action: 'register' })
    });
  }
});

When to use server token

Sign-up, payment, password reset — any flow where the cost of a successful bypass is high enough to justify the extra round-trip. The server token binds verification to a specific session and IP, so an attacker can't grab a token from one user and replay it for another. For low-stakes flows (newsletter signup, comment posting), it's overkill.