---
title: "Signup Protection Integration: Browser and Server | Emvero"
description: "Plan your Signup Protection integration. Connect your registration form and server, choose email and signals or signals only, and verify your first check."
url: https://emvero.io/signup-protection/integration/
language: en
updated: 2026-10-31
---

# Connect Signup Protection to your registration flow.

Add visit-token collection to your registration page, check the submission from your server and apply Emvero's recommendation before granting access.

This overview explains what you need to change and how the parts fit together. The documentation provides the installation code and full API reference.

Start for free

View documentation

Requires access to your registration page and a server-side step.

## Before you start

You need an Emvero account with a confirmed email address, an HTTPS registration page you can edit, and a server-side step that runs before the new account receives access. With hosted authentication or a form builder, check that you can add the browser scripts and run your own server check at that point.

You also need enough credits for the check’s maximum reserve. Evaluated signals cost 5 credits; email verification is charged separately. An unusable token or unavailable signals result costs 0 for the signals part, but still requires enough available balance for the reserve when the operation starts. See [pricing](https://emvero.io/pricing/).

For the product’s use cases and capabilities, read the [Signup Protection overview](https://emvero.io/signup-protection/).

## 1. Enable the connection and create a page key

Open [Signup Protection in your account](https://emvero.io/account/signup-protection/) and enable the connection. Wait until the connection reports `ready`, then create a page key for the HTTPS origin of your registration page.

An origin contains the scheme, hostname and optional port, such as `https://signup.example.com`. It does not contain a path or query. The public page key is used in the browser; a separate secret API key authorises checks from your server.

The account area provides your connection details and browser snippet. The [embedding guide](https://docs.emvero.io/using/signup-page/) covers origins, the versioned script file and Content-Security-Policy settings.

## 2. Collect a token when the form becomes visible

Install the token script and the separately served browser probe, then add a hidden token field inside your registration form. Start collection when the form becomes visible, after applicable consent. For a form in a dialog, start when the dialog opens.

Write the returned token into the hidden field so the form carries it to your server. On a long form, refresh it before expiry and update the field again. Waiting until submission to collect the first token can make an ordinary signup appear unusually fast.

Follow the [browser installation instructions](https://docs.emvero.io/using/signup-page/) for the current files, initialisation code and refresh behaviour.

## 3. Check the submission from your server

Read the submitted token in your registration handler. Forward the IP address, User-Agent and Client Hints your server actually received, following your trusted proxy configuration. Omit unavailable comparison inputs.

Choose the route that matches your email-verification flow:

| Route | Use it when | What it returns |
| --- | --- | --- |
| `POST /v1/signup-checks` | Emvero should check the email address and visit together. | The email result, visit findings and one combined recommended action. |
| `POST /v1/signup-signals` | Your application checks email separately or uses another provider. | Visit findings and an action for the signals alone. |

Both routes require your secret API key on the server. The signals-only route does not accept `email` or `variant`. For a combined check, `variant` selects `full` or `domain` email verification; a domain check cannot establish that a particular mailbox exists.

See the [Signup Protection API guide](https://docs.emvero.io/using/signup-protection/) for request examples, fields and authentication.

## 4. Apply the recommended action before granting access

In a combined response, read the outer `action`. The nested `email.action` describes the email check alone and can differ when a visit finding requires confirmation.

| Recommended action | Your application’s next step |
| --- | --- |
| `allow` | Continue according to your registration and access rules. |
| `allow_with_email_confirmation` | Send your confirmation email and require completion before granting the relevant access. |
| `reject` | Handle the email rejection in your registration form. This action comes from the email check. |

Visit signals can require confirmation; they never recommend rejection on their own. VPN, Tor, proxy and hosting findings are informational by default. Your application owns its confirmation messages and access rules.

The [signal-code reference](https://docs.emvero.io/answers/signal-codes/) explains individual findings and their default actions.

## 5. Handle missing evidence and pending results

These results need different handling:

| Result | Meaning and next step |
| --- | --- |
| Missing or unusable token | The visit cannot be assessed through that token. Signals report `token_unusable` and require confirmation when the email result would otherwise allow registration. |
| Signal service unavailable | `signals.status` is `unavailable`. A combined action follows the email result; a signals-only action is `allow` without a visit assessment. Apply your chosen outage policy. |
| Email still pending | The combined action requires confirmation while email is pending. Retrieve the saved check after `email.retry_after_ms`; the visit is not evaluated again. |

A blocked browser script can leave the form without a token. That is different from an unavailable signal service. Likewise, an individual browser comparison can be reported as not evaluated while the overall signals result is `evaluated`.

For transport retries, keep the same `Idempotency-Key` and body for the original operation. See [pending checks](https://docs.emvero.io/using/pending/) and [idempotency](https://docs.emvero.io/using/idempotency/) for the full contract.

## 6. Verify the complete registration path

Submit a test registration through your own allowed HTTPS origin and server. Inspect the saved result and confirm that:

- the form supplies a token and your server forwards the available request details;
- the result reports `signals.status: evaluated`;
- your application applies the outer action before granting the relevant access;
- confirmation and unavailable-result handling follow the rules you chose.

A ready connection, a page key or recorded browser traffic does not confirm that this path works. An evaluated check confirms an evaluation; you still need to verify your application’s response to it.

Read the [privacy policy](https://emvero.io/privacy/) and [security information](https://emvero.io/security/) when planning collection, retention and removal. Emvero processes visit data within its own EU infrastructure; the 30-day signal-result retention period does not cover every connection observation or statistic.

## Frequently asked.

**What if somebody takes a long time to complete the form?**

Refresh the token before it expires and update the form field with the returned value. The current token profile uses a 15-minute lifetime. The [embedding guide](https://docs.emvero.io/using/signup-page/) explains refresh timing and when the first issue time is preserved.

**Will a request retry look like a reused token?**

Retry the same operation with the same `Idempotency-Key` and request body within the 30-minute replay window. It returns the saved check without another evaluation or charge. Presenting an already used token in a new operation is different and can require email confirmation.

**How do I stop using Signup Protection?**

Stop sending server checks and remove the browser scripts. Revoke unused page keys in your account; changes take effect after synchronisation. To remove the product connection, [contact Emvero](https://emvero.io/contact/). Connection removal is handled by an operator and does not erase every shared observation or aggregate. See the [privacy policy](https://emvero.io/privacy/) for retention and deletion details.

## Set up the connection in your account.

Enable Signup Protection, create a page key and follow the browser and API documentation. Complete a check through your own registration page to verify the integration.

Start for free

View documentation