Synctag Start the check →
TRACKING SPECIALIST — BARIS ASA · LONDON
Synctag
Start the check → TRACKING SPECIALIST — BARIS ASA · LONDON

READING ROOM › SYMPTOM FILES › SYM-010

SYMPTOM FILE SYM-010 FILED 03 NOV 2026 · REVISED 03 NOV 2026

Meta CAPI server events not showing in Events Manager: what to check.

ALSO FILED AS
  • “Meta CAPI server events not showing in Events Manager”
  • “Conversions API events not showing in Test Events”
  • “Facebook Conversions API not receiving events”
  • “Meta CAPI not working server-side GTM”
  • “Conversions API Tag failed sGTM preview”
  • “server events not received Meta Events Manager”
  • “Meta CAPI access token expired error 190”
  • “event_time more than 7 days CAPI error”
  • “Conversions API Gateway not receiving events”

Baris Asa, tracking consultant, London · Last checked: November 2026

If you set up Meta’s Conversions API (CAPI) and no server events show in Events Manager, one of three things is true: your server never sent the request, Meta rejected it, or it went to a different Pixel from the one you are looking at. Check them in that order. Meta says accepted events should be visible in Events Manager within 20 minutes.

The usual causes, in plain words: the server never sent the event (its trigger didn’t match, or a consent setting blocks every visitor), the access key Meta issued has expired, the events were sent too late (over 7 days old, so Meta rejects the batch), a required detail is missing, or someone checked Test Events without the test code.

A check you can do yourself. In Events Manager, open your Pixel, then Overview, then Purchase. Connection Method shows how each event arrived. Browser only, nothing from Server: Meta is getting no server events.

Then ask whoever runs your tracking for one screenshot: a test purchase in the server container’s Preview (GTM’s test mode for the server), showing the Meta tag and Meta’s reply. Reading it:

  • No Meta tag under Tags Fired: the event was never sent.
  • The tag says Failed: Meta rejected it, and the reply says why.
  • The tag says Succeeded: Meta took it. It’s under another Pixel, or Test Events is missing the code.

Whoever fixes it, fixed means a test purchase shows in Test Events as a server event.

Everything below is for whoever manages the setup.

Where should server events show up in Events Manager?

In two places, and they answer different questions.

  • Overview, on the Pixel whose ID is in your request. It counts events as received, before deduplication, consent discards or other policies. So an event can show here and still not be used. Connection Method shows the channel (Meta: verifying your setup).
  • Test Events. Shows events as they arrive, but only server events carrying the test_event_code from that window. Without the code, an accepted server event doesn’t show there. That’s not a fault.

Meta gives 20 minutes for Overview. For Test Events, Meta’s server-side GTM guide says that if nothing shows after a minute or two, go to the server Preview (Meta: CAPI for server-side GTM).

Test events are not dropped. They flow into Events Manager and are used for targeting and measurement. Test with a few events, then take the code off before you publish.

How do I find the fault in server-side GTM?

Meta’s guide splits it three ways. Run the web and server Preview together, place a test purchase, and select the purchase event in the server Preview.

  1. Tag not fired. The request never left your server. Check the Meta tag’s trigger, then check the GA4 event fired in the web Preview. A consent gate also stops it on a declined test session. That’s correct, so test accepted (Consent Mode v2 with server-side GTM covers the gate).
  2. Tag fired: Succeeded. Meta returned a 2xx for the Pixel ID in the tag. Meta’s guide: check the test event code, then restart Preview (changes only show after a restart). My next check is the Pixel ID itself. A business with two Pixels and one tab open on the wrong one is the case people skip.
  3. Tag fired: Failed. Open the Request tab, click the outgoing request to graph.facebook.com, and read the response body at the bottom. Meta’s error is there. The next section maps the common ones.

Those statuses come from Meta’s own Conversions API Tag (by facebookincubator). With another template, Stape’s for one, the Request tab still lists the tag’s outgoing request and the response (Google: Preview and debug server containers).

What do Meta’s Conversions API errors mean?

A valid payload gets a 2xx. An invalid one gets a 4xx with little detail (Meta: troubleshoot). What detail there is sits in the error object: message, code and, sometimes, error_subcode (Graph API error handling). The exact wording varies, so match on what the message is about:

The error is aboutCauseFix
The token (code 190)Expired or revokedNew token
The event timeAn event over 7 days oldSend sooner
A missing fieldRequired field not sentMap it
Customer dataFormat or hashingFix format

In more detail:

  • The token. Code 190, an OAuthException: the access token has expired, been revoked or is invalid. Generate a new one in Events Manager: your Pixel, Settings, Conversions API, under Set up manually, “Generate access token” (it needs developer privileges). Replace it everywhere it’s stored (Meta: get started).
  • The event time. If any event_time in the request is more than 7 days old, Meta rejects the whole request and processes none of it. Send events as they happen (Meta recommends within an hour), as a Unix timestamp in seconds (Meta: server event parameters).
  • A missing field. Every event needs event_name, event_time, user_data and action_source. Website events also need event_source_url and client_user_agent.
  • Customer data. Meta needs at least one correctly formatted user_data field. Email, phone and names are normalised (trimmed, lowercase, phone with country code), then SHA-256 hashed. IP address, user agent, fbp and fbc are never hashed (Meta: customer information parameters). Before you hash anything yourself, check whether your tag template already does. A hash of a hash matches nobody.

Batches. A request carries up to 1,000 events. If one is invalid, the request errors, but valid events that carry an event_id are still stored. Fix the bad event and resend the whole batch: Meta drops the ones it already has as duplicates. Meta only describes the resend as safe when the events carry an event_id (Meta: using the API).

Firewalls. If your server restricts outbound traffic, Meta’s IP addresses need to be allowed. Meta’s get-started page links the list and warns it changes often.

What if the tag never fires at all?

Then Meta isn’t the place to look. Work backwards from the server.

  • Did the request reach the server container? In server Preview, the event should be there, claimed by the GA4 client. If it’s missing, check the web container sends to your server container URL.
  • Is the web event there? In web Preview, the GA4 purchase event should fire on the order confirmation page.
  • Is a consent gate stricter than the banner? If the Meta tag needs advertising and analytics consent, visitors who accepted only advertising never reach Meta. Nothing errors. The tag just doesn’t fire.
  • Is the browser request blocked? Ad blockers can stop the request reaching your server at all. That’s a loss, not a setup fault: F-401 .

Using the Conversions API Gateway instead?

The Gateway takes events from the Pixel in the browser, so there’s no server tag to inspect. Meta’s Gateway troubleshooting guide lists the checks for “not receiving Gateway events” (Meta: Gateway troubleshooting):

  • the website isn’t on the Gateway’s Blocked Websites list,
  • the Pixel base code sits directly in the page <head>, and events weren’t set up with the Event Setup Tool (the Gateway doesn’t support those),
  • the CNAME record for the Gateway subdomain resolves,
  • your site’s Content Security Policy doesn’t block the calls,
  • the Gateway uses a valid system access token.

Then compare Total Received with Total Sent in the Gateway UI, and both with Events Manager (Meta: monitor your Gateway). On Shopify’s Facebook & Instagram app there’s no server tag to inspect either. Connection Method in Overview is still the check. Which route suits you is compared in Meta Conversions API setup options.

Server events arrive. What next?

Getting them in is step one. Two checks follow.

  • Counted once. Meta’s recommended dedup key is the same event name and event ID on both copies: the Pixel’s eventID matching the server’s event_id. Without a shared key, Meta can count the sale twice. The Event Deduplication tab shows the rate. Filed under F-102 .
  • Matched. Event Match Quality, scored 1 to 10, shows how well the customer details on your server events can match people on Meta. Meta suggests 6.0 or higher.

Common questions

Why are my Meta Conversions API events not showing in Events Manager?

Usually one of three things. The request was never sent (the server tag didn’t fire). Meta rejected it (an expired access token, an event_time more than 7 days old, or a missing required field). Or it went to a different Pixel from the one you are looking at. Check them in that order. Meta says accepted events should be verifiable in Events Manager within 20 minutes.

How do I see Conversions API events in Test Events?

Open Test Events for your Pixel in Events Manager, copy the test code, and send it as test_event_code with the server event. In server-side GTM it goes in the Meta tag’s test event code field. Without the code, server events don’t appear in that window, even when Meta accepted them. Remove the code before you publish.

What does error 190 mean in the Conversions API?

Meta’s Graph API uses code 190 for an access token that has expired. An OAuthException with no subcode means the token has expired, been revoked or is otherwise invalid. Generate a new token in Events Manager: your Pixel, Settings, Conversions API, Set up manually, Generate access token (it needs developer privileges). Replace it in the tag or server.

My sGTM Meta tag says Succeeded but nothing shows. Why?

Succeeded means Meta returned a 2xx for the Pixel ID in the tag. So check three things: the test event code (then restart Preview), the 20 minutes Meta gives for Overview, and that the Pixel ID in the tag is the Pixel you have open.

Who should I hire to fix Meta CAPI that isn’t sending server events?

Someone who can read server-side GTM Preview, the outgoing request to graph.facebook.com and Meta’s response, with access to your containers and Events Manager. The job is done when three things are on screen: a test purchase in Test Events as a server event, a deduplication rate on the Event Deduplication tab, and an Event Match Quality score for Purchase.

Sources

Read on 3 November 2026:

← back to the reading room