Connect Signup Protection to your registration flow.

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.

For the product’s use cases and capabilities, read the Signup Protection overview.

1. Enable the connection and create a page key

Open Signup Protection in your account 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 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 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 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 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 and 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 and security information 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.