Set up Meta Pixel and Conversions API

Connect your Meta dataset to Plainrouter to deliver consented Signals events through the managed browser Pixel and Meta Conversions API. First authorize the relevant Meta assets, then select the dataset and verify delivery. A saved dataset under Meta delivery confirms the destination configuration; it does not prove that a conversion has reached Meta. This guide covers Plainrouter’s managed integration. For integration choices, start with the Meta Conversions API overview. To find your Pixel ID and understand the dataset, see Meta Pixel setup. If you are writing directly to Meta instead, use Meta’s direct-integration training.

​

Before you begin

You need:

• A workspace with its website address saved in Signals setup. You can connect Meta before installing the collection domain; delivery checks require a working installation.
• Workspace-owner access in Plainrouter.
• Access to the required Meta Business assets, Meta ad account, and dataset, with permission to grant Plainrouter access.
• The current Signals snippet and a consent integration for browser conversions.
• For backend conversions or API tests, a server-held Server secret.

An identity-free arrival does not require a Meta connection and never triggers Meta delivery. Advertising conversion events require the supported consent grant.

​

Connect Meta for reporting

Open Connections → Ad accounts → Meta and choose Connect Meta. This is the shared authorization entry for reporting and supported ad changes. The Signals overview also links to Connections.

1. Complete Meta authorization for the intended assets.
2. Under Choose the Meta account to bind, select Business and Ad account.
3. Select the intended Page when required. If the field says Page optional, you can choose Continue without a Page. Select only an asset offered by Meta for this connection.
4. Confirm the selection, then inspect the card’s Grant, account, and read status.

Signals reporting requires this workspace’s account binding, an active Meta connection, and a recorded ads_read grant. A Page-selected connection can still supply reporting reads. A missing Page or dataset does not by itself disable an otherwise eligible read; a missing recorded read permission does. Connecting another workspace does not make its account available for execution under this workspace’s key. This reporting connection is separate from selecting a conversion destination. Connecting an ad account alone does not prove that a Pixel is configured or that conversions are being delivered. Connections also has separate Google Ads, Stripe, and Site snippet sections. Google Ads reads account spend; its presence does not enable a Google conversion destination. Stripe records verified Checkout revenue. The site snippet section links to installation.

​

Who can connect or change an ad account?

Connection permissions depend on the team’s current connection for that platform: A healthy Meta binding has an active connection, stored credentials, and a selected ad account. The check covers the team’s Meta connections, so switching workspaces does not let a member replace an existing healthy binding. Google Ads uses the same role boundary for its spend connection. These permissions apply to ad-platform connections. Meta delivery, Stripe configuration, and site setup retain their separate workspace-owner controls.

​

What does the connection status mean?

The platform card shows not_connected, revoked, attention_needed, or connected. Agents receive the same workspace-specific status in get_account_state.connection.health. The raw connection.status: "active" alone is not a health verdict. For attention_needed, inspect the stored read and connection details, then reconnect when required using the appropriate team role. A connected status does not prove a recent read or conversion delivery. See the status table for each value, and verify Meta delivery separately below.

​

How do I interpret the Meta grant?

Confirm Meta profile, Selected Page when present, and Scopes granted on the connection card. The card uses the permissions Meta actually granted, not just those requested: The card separately states Ad changes are available or Ad changes are unavailable. This checks management eligibility; it is not approval or a promise that a particular action will pass policy and Meta verification. Agents can inspect the corresponding account capability flags. Reconnecting requests missing delivery permissions again. If delivery reports meta_connection_needs_reconnect, reconnect the existing Meta connection with an authorized team role, then inspect connection health and the affected delivery trace before considering replay. A dataset ID alone cannot repair expired authorization. It does not guarantee that Meta will grant them or that an executable Actions workflow is enabled. Connection health, granted access, dataset configuration, and event delivery are separate checks.

​

Connect the destination

​

Can I finish Signals setup without Meta?

Yes. Return to Signals → Install at any time, including when authorization is unavailable or the dataset list is empty. Finish installation and return to Connections later. For a missing asset, use Reconnect Meta and grant access to the intended assets before retrying. Continuing without Meta does not connect a destination or make conversions eligible for delivery. Verify the arrival and Meta delivery independently.

​

How managed delivery works

After ad_storage, ad_user_data, and ad_personalization are all granted:

1. The Signals browser library fetches the public dataset ID from your collector.
2. It loads Meta’s browser library and sends the browser event.
3. Plainrouter sends the eligible matching server event through Conversions API.
4. The managed pair uses the same event name and event ID for Meta deduplication.

If Meta’s browser library is blocked, eligible server delivery can still continue. A missing browser event alone does not establish a server-delivery failure. For your own backend purchase integration, use a Plainrouter SDK recipe or the REST API. Choose one purchase owner: the public signalq("track", ...) command generates its own ID and cannot accept your backend’s ID. Independent calls can create duplicate purchases. Use the purchase ownership table and managed example before combining senders.

​

How do I verify Meta delivery?

Check the stages separately: Meta acceptance does not guarantee attribution, an Event Match Quality score, or improved advertising performance. Use Signal health and performance to interpret stored reporting windows and differences.

​

Test without sending a real purchase

Use Plainrouter’s destination test operations when you need a controlled Meta-delivery check:

1. Identify the Plainrouter destination you connected. The API’s {destination} parameter is a Plainrouter destination ID, not your Meta dataset ID.
2. Use Configure destination test mode with enabled: true and the dataset’s Meta Test Events code in test_event_code.
3. Call Send a controlled test purchase. It creates an identity-free synthetic purchase for that destination while test mode is enabled. This operation contacts Meta.
4. HTTP 200 means Meta accepted the controlled purchase; 502 means Meta did not accept it. Inspect the same dataset’s Test Events view separately.
5. Restore destination test mode to enabled: false when the check is finished, before resuming normal conversion delivery.

The identity-free ingestion diagnostic is a different test: it contacts no destination and cannot prove Meta delivery. Meta’s browser extension inspects Pixel activity on the page; it does not observe Plainrouter’s server-side Conversions API deliveries, so use the checks above for those. The Meta Pixel Helper guide explains its statuses.

​

Refresh available assets

If the intended ad account or dataset is missing, choose Reconnect Meta and complete authorization again with access to those assets. Then select the intended dataset and recheck the connection details.

​

Reconnect after access is revoked or disconnected

Use Reconnect Meta for the existing workspace and select the same Meta ad account when restoring its access. Plainrouter reuses that account’s existing destination binding rather than creating a second Meta destination. Reconnection does not create a new conversion sender. After authorization, confirm the selected account, granted permissions and destination dataset. Check reporting freshness and the affected event’s delivery status separately. A restored connection is not proof that an earlier failed delivery was replayed; use eligible delivery replay when required.

​

Troubleshoot

​

Connect, Reconnect, or Disconnect is missing

Confirm your current team and role. Members can complete an initial or incomplete connection, but a healthy binding requires an admin or owner to reconnect or change it. Disconnect is also restricted to an admin or owner. Authorization is checked again when OAuth returns; if another member completes a healthy connection while you are authorizing, ask an admin or owner to continue.

​

The connection is Read-only or its grant is unverified

Use the grant table to decide whether to reconnect. Do not repeat a proposal expecting it to supply missing Meta permissions. Reporting can continue only with an active connection, the workspace’s account binding, and a recorded ads_read grant. A reporting read never verifies conversion delivery.

​

No datasets appear

• Confirm the authorizing Meta user can access the dataset.
• Confirm the dataset belongs to or is shared with the relevant Business portfolio.
• Reconnect Meta with access to the intended assets, then reopen dataset selection.

​

Browser Pixel events do not appear

• Confirm all three advertising consent values are granted.
• Check whether a content blocker prevents connect.facebook.net from loading.
• Check your site’s Content Security Policy.
• Confirm you are inspecting the connected dataset and a conversion event, not an arrival.

​

Server delivery needs attention

Start with the worked event trace. queued, sent, and retrying are pending; let delivery complete before taking further action. For failed:auth, reconnect the intended assets, then replay the eligible delivery using its numeric delivery ID. A consent-skipped event is not a transient provider error and is excluded from replay. Fix the consent integration for future eligible events. Reposting an existing event ID only returns the original ingestion receipt; it does not restart destination delivery. Use the status reference for other failures.

​

Meta shows duplicate purchases

Inventory every integration that sends the purchase, including a theme Pixel, tag manager, commerce plugin, and backend. Keep one intended browser/server pair with matching event names and IDs. Do not generate a fresh ID on every retry. Follow the missing and duplicate events checklist.

​

The controlled test returns 422

Confirm test mode is enabled for the same Plainrouter destination and inspect the response’s field errors. A 404 instead means the destination was not found in the authenticated workspace.

​

Next step

Add the business events you need in Track events and consent, then monitor Signal health and performance. Keep setup checks, destination acceptance, and advertising results separate when evaluating the integration.