Monitor your first website free - no card needed. Explore SENRIKO

Check depth · with the header

Stopping monitoring submissions reaching your team

A form check sends one real enquiry, because nothing else proves the form works. Teach your server to recognise it by our header and discard it: the check still proves the path up to your server, and nothing reaches a person.

Code for your serverOther ways

What your server does
SENRIKO checksubmits the form with the X-Senriko-Monitor header
Your form handlerDoes the header match your token?
yes
Answer as usualthe same thank-you page, store nothing
no
Normal handlingCRM, email, a salesperson

Real visitors never send the header, so their enquiries go through as before.

Three ways

How to check a form without bothering your team

These are three of the check depths in your dashboard. The header fits when the form handler is yours and you can add a few lines to it.

  • Safe Check

    The enquiry never leaves the browser. Proves the page loads and the form submits.

    What it takes: nothing, every form starts here.

  • With the header

    This page

    The enquiry reaches your server, which discards it. On top of Safe Check: your server accepted it and the conversion was recorded.

    What it takes: a few lines in your form handler, which is what this page is about.

  • With a CRM filter

    The enquiry reaches your CRM and a rule moves it straight to a test pipeline. All five steps, CRM delivery included.

    What it takes: a rule in your CRM and the site owner’s consent. Recipes for 12 systems

Steps: 1 the page loads, 2 the form submits, 3 the server accepts it, 4 the conversion is recorded, 5 the CRM receives it.

What this buys you

Two things. Nobody on your team ever sees a monitoring enquiry, because it never becomes one - your handler answers normally and stores nothing. And the frequency ceiling lifts: a check whose submissions reach a person is held to once a day on purpose, because twenty-four synthetic leads a day is a decision about somebody's working morning rather than a monitoring setting. A check that reaches nobody can run as often as your plan allows.

If you change nothing

What the test enquiry looks like in your CRM

Every check submits as the same made-up person, and keeps the same values for as long as the check exists. All four are things a CRM rule can match on.

Match the domain checks.senriko.com, not the whole address: the address carries the check’s id, and a new check gets a new one. If the handler cannot be changed, a CRM filter catches the enquiry by the same signs.

How to set up a filter in your CRM
New enquiry from the websiteName and the other fields as you set them in the wizardTest
Email
monitor-<id>@checks.senriko.com
Phone
+1 201 555 01NN
Hidden field
utm_source=senriko-monitor
Message starts with
[SENRIKO TEST <id> - DO NOT CONTACT]
An example. The wizard shows your check’s real values. The number is from a reserved range and reaches nobody.
The header

What we send, and where to find the token

Every request a check makes to your website carries a header naming the workspace it belongs to. Requests to other services on your pages, such as analytics or a chat widget, do not, with one exception: when your own site redirects a request to another service, the browser carries the header there too. Nothing else sends it, and nobody else can guess it.

X-Senriko-Monitor: your-workspace-token

Your token is in the form check wizard, beside the box that declares this is set up, and in Settings, Test identity, where the owner can replace it. Treat it as a secret: anything that knows it can make a request your site will discard.

The form check wizard: the header with your workspace token, and the box that declares your website discards these submissions.
On your server

Four steps in your form handler

  1. Read the header

    It is X-Senriko-Monitor, on the incoming request. Only our checks’ requests carry it.

  2. Compare it to the token

    With your workspace token, using a constant-time comparison if your language offers one.

  3. Skip the side effects

    If it matches, skip everything the submission would normally trigger - no CRM record, no notification, no email to your sales team.

  4. Answer as usual

    The same status code, the same redirect, the same thank-you page.

That last step is the one that matters. The check reads what a visitor would see, so a handler that discards the submission and then returns an error will be reported as a broken form - correctly, because that is what a visitor would get.

Code

The same four steps, in code

Whichever of these your site is built on, the shape is identical: read the header, compare it in constant time, skip the side effects, and answer exactly as you would have.

SENRIKO_TOKEN is your workspace token, from the form check wizard. Keep it in your environment, not in the file: anything that knows it can make a request your site will discard.

$token = getenv('SENRIKO_TOKEN');
$sent = $_SERVER['HTTP_X_SENRIKO_MONITOR'] ?? '';

// Both must be set: an empty token would match every visitor who sends no header.
if (is_string($token) && $token !== '' && $sent !== '' && hash_equals($token, $sent)) {
    // Answer exactly as you would have, and do nothing else.
    header('Location: /thank-you', true, 303);
    exit;
}

On something else? Any framework that can read a request header can do this. The only part worth care is the comparison: use your language's constant-time equality rather than ==, and handle a header of the wrong length without erroring.

Check that it works

The wizard sends a trial enquiry with the header

Tick “Our website discards submissions carrying this header” and press “Try it once”. If your server answers an unfamiliar header with an error, you see it at once rather than silently every hour after setup.

Questions

What developers ask

Is this a hole in your form?
It is a header, so anybody could send it. That is exactly why it must only ever make you do less, never more. Discarding a submission is safe. Skipping validation, skipping a captcha, returning a different status code, or trusting any other field because the header is present would not be. To let our checks past a CAPTCHA or a firewall, match our address as well as the token: the token can leave your site with a redirect, our address cannot. If your handler branches on the header to do anything except stop early, take the branch out.
Do you need to check the token?
The header carries a token unique to your workspace, so you can check that a request naming us is actually ours. Checking it is optional: the worst an impostor achieves by sending the header is to have their own submission discarded. Check it if your handler does anything beyond discarding, and check it as a constant-time comparison rather than with ==.
Why does SENRIKO take your word for it?
We cannot see inside your backend, so this is a declaration rather than something we verify - and the interface says so where you make it. What we do verify is that the form still behaves normally with our header on the request: the trial run has to pass with the header present, so a backend that rejects unfamiliar headers outright fails at setup rather than silently every hour afterwards.
What does it not change?
The check still opens your page, still fills the form in, still presses the button, and still watches for the conversion signal - so everything above the server's answer is proved exactly as before. What changes is only where the submission ends up. And the Proof Level says so: with the submission discarded by you rather than delivered, the CRM-delivery rung stays unconfirmed, because nothing arrived to confirm it.
What it proves

Four steps of five. Only your CRM can prove the fifth

With the submission discarded, the check still proves the page loads, the form can be filled in and submitted, the server accepts it, and your conversion signals fire. It stops proving that a lead reaches your CRM, because you have asked us not to send one. If that last step is what you need watched, leave the submissions arriving and filter them in your CRM instead.

Filter recipes for 12 CRMsSet up a check

  1. The page loadsProved
  2. The form submitsProved
  3. The server accepts itProved
  4. The conversion is recordedProved
  5. The CRM receives itNot checked