---
title: 'Meta Pixel and CAPI not working? Troubleshoot missing events'
description: Fix missing Meta Pixel and server events, including React and Next.js route changes, duplicate triggers, consent, delivery, and reporting.
published_at: 2026-09-04
last_updated: 2026-09-17
format: Guide
---

# Meta Pixel and CAPI not working? Troubleshoot missing events

Missing Meta Conversions API events can originate before collection, during validation or delivery, or in the report you are inspecting. Start with one known conversion, find the last confirmed step, and investigate the next step before resending it.

This guide covers Meta Pixel and Conversions API troubleshooting, with Plainrouter examples where the behavior is specific to Plainrouter. The examples use fictional records. They demonstrate diagnostic checks, not production delivery results.

## Where should you start when an event is missing?

Start where you last have evidence. A loaded browser script, an accepted collector request, and a conversion attributed to an ad are different observations.

| What you see                                                           | First check                                                                              | What the observation does not prove                               |
| ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| The snippet loads, but no event request appears.                       | Consent state, the business-event trigger, browser console, and Content Security Policy. | Loading a script does not prove that it sent an event.            |
| The collector returns a validation or authentication error.            | The response fields, credential type, endpoint, and request shape.                       | Sending a request does not mean it was accepted.                  |
| Plainrouter returns HTTP `202`, but Meta shows nothing.                | The accepted event's delivery trace, connected dataset, and test-mode state.             | Collector acceptance does not prove Meta delivery.                |
| Plainrouter returns `duplicate: true`.                                 | Whether the request is a retry of an already accepted event ID.                          | API idempotency does not prove Meta browser/server deduplication. |
| One purchase appears twice.                                            | Event names, event IDs, dataset IDs, and other senders for that order.                   | Two requests do not necessarily represent two purchases.          |
| Meta receives the event, but Ads Manager does not credit a conversion. | The report's date range, attribution settings, and available matching context.           | Receipt does not establish ad attribution.                        |
| Event Match Quality falls.                                             | The affected event type and its permitted customer information.                          | A matching score is not a delivery-success percentage.            |

Follow this sequence for the affected event:

```text
Business event occurred
  -> collection permitted and triggered
  -> collector accepted the request
  -> destination delivery attempted and accepted
  -> browser/server pair checked, if both were sent
  -> matching and attribution examined separately
```

An intentional consent stop is not a delivery defect. A server-only event also has no browser copy to deduplicate. Meta's [Conversions API optimization training](https://www.facebookblueprint.com/student/page/566594-optimize-meta-conversions-api) treats event coverage, matching, deduplication, and freshness as separate areas to investigate.

## How should you use Meta Pixel Helper when events are missing?

Start with the browser event you expected, then check its destination separately. Seeing a browser event does not establish that a server event was delivered or that an ad received conversion credit.

Meta's official Chrome extension is now listed as [Meta Ads Data Advisor, formerly Meta Pixel Helper](https://chromewebstore.google.com/detail/meta-ads-data-advisor/fdgfkebogiimcoedlicjlajpkdmockpc). The listing says the existing diagnostics remain available and describes additional setup and repair capabilities. Use the listing offered by Meta; the old name also appears on other extensions.

For one controlled test, note the expected event, destination dataset and trigger. Complete the action once with the appropriate consent decision, then compare what you expected with the browser diagnostics and request. Avoid treating a page reload as another purchase.

| Observation | Next check |
| --- | --- |
| No browser Pixel is detected | Confirm whether this integration is supposed to send a browser Pixel event. Then check the installed script, consent state and browser errors. |
| PageView appears, but the expected Lead or Purchase does not | Inspect the specific business-event trigger. A page view does not confirm that a separate conversion event ran. |
| The browser event appears, but the server event is missing | Inspect the server submission response and destination delivery outcome for that event. |
| Both browser and server copies appear | Compare their event names and IDs using the [deduplication guide](/library/meta-event-id-deduplication). |

For a server-only integration, absence of a browser Pixel is expected. For Plainrouter, inspect the accepted event's delivery trace before resending it. An extension observation or a clean [local payload check](#local-check) alone cannot establish destination acceptance.

Keep matching, coverage and deduplication checks separate, as outlined in [Meta's Conversions API training](https://www.facebookblueprint.com/student/page/566594-optimize-meta-conversions-api). Once delivery is confirmed, use the reporting checks below to investigate missing ad attribution.

## Why is the browser not sending an event?

Check that the business event actually occurred and that the consent decision permits collection. Then inspect the browser request. A purchase should follow your confirmed purchase trigger; simply visiting or reloading a thank-you page does not establish a new order.

For the Plainrouter browser integration:

1. Confirm the generated script loads from your configured first-party collection domain.
2. Check the console and network panel for script errors, blocked connections, or Content Security Policy failures.
3. Inspect the resolved CMP state. Plainrouter sends ordinary browser events only when `ad_storage`, `ad_user_data`, and `ad_personalization` are all `granted`.
4. Confirm the application calls `signalq('track', ...)` when the intended business event occurs.
5. Inspect the event request to `/v1/events` on the collection domain and its response.

Plainrouter's browser collection endpoint and server Conversion API are different interfaces. Server integrations use `https://plainrouter.com/api/v1/events` with a Signals workspace secret. That secret must stay out of browser code.

If consent is unresolved, fix the CMP connection or wait for its decision. Do not replace unknown or denied values with grants to make a test pass. See [server-side tracking consent](/library/server-side-consent) and the [direct installation guide](/library/meta-capi-without-gtm).

## Why is Facebook Pixel not working in React or Next.js?

Separate **script loading, route navigation, and the conversion trigger**. A Pixel that works after a full reload can still miss a client-side transition. A component mounting twice does not mean two purchases occurred. Check the browser request for the action you expected before adding another tracking call.

### It works on reload but not after navigation

Compare a direct page load with navigation through your app's links. Keep the Network panel open and check whether the expected event is sent on each path, with the same consent choice. Then inspect the integration's route-change handling; do not assume loading the script also tracks every navigation.

For the Next.js App Router, [`usePathname`](https://nextjs.org/docs/app/api-reference/functions/use-pathname) provides the current pathname in a Client Component and updates as navigation changes it. Check whether your existing integration already observes navigation before adding a listener. Keep page-view handling separate from the confirmed action that produces a Lead or Purchase.

### The tracking function is unavailable when the action runs

Inspect script-loading errors and the order of initialization, consent resolution, and event dispatch. Next.js [`Script`](https://nextjs.org/docs/app/api-reference/components/script) supports load callbacks in Client Components; `onReady` also runs on subsequent component mounts. It is not a once-per-purchase callback. Avoid initializing competing copies through a layout, a tag manager, and a manual snippet.

### Events appear twice in local development

[React Strict Mode](https://react.dev/reference/react/StrictMode) can run an extra Effect setup/cleanup cycle in development. If an Effect sends a conversion merely because a component appeared, inspect that trigger and compare with a production build in your test environment. Do not disable Strict Mode as the tracking fix or assume every duplicate is caused by React.

Tie the event to the confirmed business action, following React's distinction between [event handlers and Effects](https://react.dev/learn/you-might-not-need-an-effect). Preserve the same [event identity for retries and browser/server copies](/library/meta-event-id-deduplication); a route change or component remount should not create a new purchase ID.

For Plainrouter's managed browser path, use the existing `signalq` integration once. Adding manual `fbq` calls alongside it can create a second sender. First identify whether the problem is a missing browser trigger or failed server delivery, then continue with the checks below.

## Does HTTP 202 mean Meta received the event?

No. A `202` from Plainrouter's `POST /api/v1/events` means Plainrouter accepted the event for processing. It does not say that Meta accepted a delivery, matched a person, or attributed a conversion. Read the event's delivery trace next.

The [Plainrouter Conversion API reference](/api/docs) documents a `Location` header on newly accepted and duplicate event responses. It points to the event detail resource. To read an event you already submitted, use its returned event ID:

```bash
curl --get \
  "https://plainrouter.com/api/v1/events/${PLAINROUTER_EVENT_ID}" \
  --header "Authorization: Bearer ${PLAINROUTER_SIGNAL_SECRET}" \
  --header "Accept: application/json"
```

Set these variables in your server environment. Use an event ID from the same workspace, URL-encoded as a path segment if it contains reserved characters. This request reads the event; it does not submit or replay it.

Use the [event detail and delivery trace](/docs/api/conversions) to determine whether a destination delivery exists and what happened to it. If no delivery exists, first check destination configuration and event eligibility. If a delivery failed, diagnose that failure before considering replay.

### What do Plainrouter error responses mean?

| Response                                   | Next action                                                                                                                      |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| `401`                                      | Check the Signals workspace secret. A publishable browser key, MCP OAuth token, or Actions workspace token is not a replacement. |
| `404` when reading an event                | Check the returned event identifier and authenticated workspace. Do not infer that the original submission failed.               |
| `422`                                      | Read the field-level validation errors. Correct the request or skip an ineligible event; do not weaken its consent state.        |
| A network timeout with no response         | The result is unknown. If retrying is still permitted, preserve the original event ID.                                           |
| `200` with `duplicate: true` after a retry | Plainrouter recognizes an already accepted event ID. Inspect the existing event's delivery instead of creating another ID.       |

These are Plainrouter responses. A direct Meta Graph API response follows Meta's own contract. Keep the responding service in the diagnostic record so that “accepted” has a clear meaning.

## Why is an n8n, Make, or Zapier run green but Meta has no event?

A successful workflow step establishes only what that step's endpoint acknowledged. Check the sender and response before retrying:

| What the workflow shows | What to inspect |
| --- | --- |
| Plainrouter sandbox HTTP `200` | `provider_delivery: false` is expected; this endpoint never sends to Meta |
| Plainrouter production HTTP `202` | Read acknowledgement warnings, then the event's delivery trace |
| Plainrouter `duplicate: true` | The ID was already accepted; repeating it does not replay a failed delivery |
| A native Meta action succeeds | Inspect that module's provider response and the intended dataset in Events Manager |
| HTTP errors appear as successful items | Check whether n8n's Never Error or an equivalent error-continuation setting is masking the status |
| Every retry creates another purchase | Check for a new UUID, execution ID, or current timestamp being mapped into `event_id` |

Also inspect the input item after filters and transformations: the expected event may have been dropped before the sender. Preserve the original purchase time and ID, and recheck consent before a queued retry. Keep one sender for each logical purchase.

Use the [n8n sandbox starter and automation setup](/library/meta-capi-without-gtm#try-an-n8n-request-without-sending-a-real-conversion) to check JSON transport, then follow the separate production mapping. Do not send real customer data to the sandbox or create another event ID to make a failed delivery look new.

## Why are accepted events missing from Meta Events Manager?

Confirm that you are viewing the dataset used by the destination, then check delivery and test mode. An event sent to another dataset will not appear in the one you are inspecting.

1. Compare the configured destination's dataset ID with the dataset open in Meta Events Manager.
2. Inspect the destination delivery outcome. Check access changes or expired credentials when delivery reports authentication problems.
3. Check whether destination test mode is enabled. Follow the test in Meta Test Events using the configured test-event code.
4. Compare the event name and occurrence time, rather than relying only on an aggregate chart.
5. Allow for the distinction between received events and later reporting. Check the timestamp of any stored Plainrouter measurement.

Plainrouter exposes `setDestinationTestMode` and `sendTestPurchase` for controlled destination testing. Use the [published test-mode workflow](/docs/api/conversions) when testing Meta delivery. The separate `verifySignalIngestion` operation checks ingestion without destination data, so it cannot prove that Meta receives events.

The [Signals health guide](/docs/signals/health-and-performance) explains delivery failures, pending measurements, and dataset configuration. Opening that dashboard reads stored measurements; it does not force a fresh Meta report.

## What if the purchase appears twice instead?

Compare the browser and server event names, event IDs, and destination dataset. Check for a checkout plugin, GTM tag, legacy Pixel, or second server integration sending the same order. A new ID on each retry or thank-you-page reload can create extra purchase identities.

Follow the [Meta event_id deduplication guide](/library/meta-event-id-deduplication) for pairing requirements, code examples, and a local mismatch check. Plainrouter's managed Pixel/CAPI path should track through `signalq` once; a second manual sender can duplicate that work.

## Should you retry or replay a missing event?

Retry a permitted request with the same event ID when the transport result is uncertain. Do not create a new purchase identity to compensate for a timeout, an empty chart, or a delayed report.

Once Plainrouter has accepted the event, inspect its delivery trace. Repeatedly submitting the same event is an idempotent ingestion retry; it is not the same operation as replaying an eligible failed delivery. Use the documented replay operation only after checking the failure and the event's current eligibility.

Preserve the actual event occurrence time when retrying. Meta's server-event contract describes `event_time` as the time the event occurred, not the time a worker retried it. Recheck consent when your policy requires it, and do not turn a denied event into another consent basis to force delivery.

## Why does Meta receive events that are absent from Ads Manager?

Event receipt and ad attribution answer different questions. Events Manager helps inspect incoming activity; Ads Manager reports conversions attributed under its reporting settings. Compare the selected account, event, date range, and attribution settings before deciding that an accepted event was lost.

Missing or incorrect matching context is another path to investigate. Check that permitted customer data belongs to the same visitor and that available browser identifiers survive checkout. A visit without a valid Meta click identifier should not be given an invented `fbc`.

Use [fbp and fbc explained](/library/fbp-fbc) to trace browser context and [Meta Event Match Quality](/library/meta-event-match-quality) to interpret matching diagnostics. Neither a high EMQ score nor a valid event ID guarantees an attributed conversion.

## What evidence should you keep when escalating a tracking problem?

Keep enough information to identify the failing step without sharing a full customer payload:

- The affected event name, a safe event reference, and occurrence time with timezone.
- Which service received the request and its HTTP status.
- The expected dataset and whether test mode was enabled.
- The delivery outcome and observation time.
- Whether browser and server event names and IDs matched.
- A field-level error message or redacted diagnostic showing the failure.

Share identifiers only through an appropriate support channel. Exclude access tokens, raw customer details, cookies, click identifiers, and unredacted browser network exports from public issue reports.

## Frequently asked questions

### Does duplicate true mean Meta removed a duplicate purchase?

No. Plainrouter's `duplicate: true` describes an idempotent API replay. Meta's browser/server deduplication is a separate destination result.

### Can missing fbc explain every missing conversion?

No. `fbc` supplies Meta click context when a valid click identifier was captured. It does not prove collection, delivery, or deduplication. Diagnose the last confirmed step first.

### Should I send a purchase again because EMQ is low?

No. A low matching score does not establish that the purchase is missing. Investigate the matching inputs on eligible events and preserve the original identity if a transport retry is needed.

### Do I need both Meta Pixel and Conversions API?

You can send server-only CAPI events. When both paths report the same conversion, coordinate their identity and verify deduplication. A server-only integration has no browser counterpart to pair.

## Sources

- [Meta: Deduplicate Pixel and server events](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events)
- [Meta Business SDK: server event identity and occurrence time](https://github.com/facebook/facebook-nodejs-business-sdk/blob/main/src/objects/serverside/server-event.js)
- [Meta Blueprint: Optimize Meta Conversions API](https://www.facebookblueprint.com/student/page/566594-optimize-meta-conversions-api)
- [Plainrouter Conversion API reference](/api/docs)
- [Plainrouter: Track events and consent](/docs/signals/track-events)
- [Plainrouter: Signal health and performance](/docs/signals/health-and-performance)

## Related guides

- [Install Meta CAPI without Google Tag Manager](/library/meta-capi-without-gtm)
- [Set up Meta event_id deduplication](/library/meta-event-id-deduplication)
- [Understand fbp, fbc, and fbclid](/library/fbp-fbc)
- [Interpret Meta Event Match Quality](/library/meta-event-match-quality)
- [Pass consent to server-side events](/library/server-side-consent)

## Check a Meta payload locally

The interactive version of this guide includes a local payload check below. Paste a native Meta Conversions API request with a top-level `data` array. It checks event fields, timestamps, customer-identifier hash shapes, browser identifiers, and value/currency pairing. Plainrouter's own event API uses a different request shape; use the [Conversion API reference](https://plainrouter.com/docs/api/conversions) for that interface.

This check does not send the payload or measure EMQ. A clean result cannot establish consent, dataset permissions, or Meta acceptance. Use the [pairing check](/library/meta-event-id-deduplication#local-check) for duplicate-event observations.