Skip to main content
Use the server-side verification event when you want to confirm that a Signals workspace secret or MCP connection can write to the authorized Signal ledger without sending customer identity or destination data.

What the verification does

It writes one idempotent, identity-free signal_verification event to the authorized Signal ledger. It does not count as real arrival evidence, complete onboarding, contact Meta, enter attribution or enforcement, or create spend.

​
Which check do I need?

​
Before you begin

You need:
  • An active collection hostname.
  • Either the Signals workspace secret for REST authentication or an MCP connection with signals.verify.

​
Test with the REST API

Store PLAINROUTER_SIGNAL_SECRET in your server environment using your credential manager. Use the Signals workspace secret, not the browser publishable key or a workspace execution token. Send an authenticated request with no body:
A new verification returns HTTP 202:
The request and response are defined by the published verification operation. Repeating the request is safe. It returns HTTP 200 with duplicate: true and does not create another ledger event.
Keep the Signals workspace secret on your server. Never put it in browser code, a URL, source control, a prompt, or a log.

​
Test with MCP

If you already have an authorized Plainrouter MCP connection, ask the client to call:
The tool accepts no input. It uses the Signal in the authorized workspace and returns the same event_id and duplicate fields as the REST endpoint. The connection needs the signals.verify permission. Read-tier workspace tokens include this permission. See Connect an AI agent or Workspace tokens.

​
Interpret the result

The result confirms that the authenticated request reached the workspace’s Signal ledger. It does not turn the setup screen green. For a managed collection hostname, setup requires a real eligible arrival or qualifying verified server revenue. The browser path uses the consent-independent /v1/arrival request sent once on document initialization. Same-origin forwarding still requires its own authenticated arrival and forwarding verification. You can use the successful diagnostic before or after you:

​
Troubleshoot

​
The API returns 401

The Signals workspace secret is missing, invalid, or belongs to another environment. Confirm the bearer header and replace a stopped credential.

​
MCP reports insufficient permission

Reconnect with signals.verify, or issue a new workspace token with the Read tier or higher.

​
MCP cannot find an active Signal

Confirm that the authorized workspace is the workspace containing the Signal and that its collection hostname has completed validation.

​
Setup still does not complete

Repeating this diagnostic will not complete setup. Confirm the collection hostname is Active, install the generated browser snippet, reload the website, and check that /v1/arrival is accepted. This arrival does not require a consent grant. See Install the Signals pixel.