Conversions API (Meta): definition, deduplication and checks

The Meta pixel runs in the visitor's browser, so ad blockers, browser privacy features and pages that close too quickly all cost events. The Conversions API gives Meta a second copy of the same events, sent from a server, which Meta then reconciles with what the pixel saw.

How it works

Your server, or a server-side tag, sends an HTTP POST to the Graph API endpoint for your dataset (pixel) with one or more events. Each server event carries:

• event_name, such as Purchase or Lead
• event_time, a Unix timestamp in seconds, at most 7 days in the past
• action_source, which is website for site events
• event_source_url and user_data.client_user_agent, both required for website events
• user_data with customer information parameters such as hashed email or phone, plus fbp and fbc cookie values where available
• event_id, used for deduplication

A minimal website purchase looks like this:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1791273600,
    "event_id": "order-10293",
    "action_source": "website",
    "event_source_url": "https://www.example.com/checkout/thank-you",
    "user_data": {
      "em": ["<sha256 of lowercased email>"],
      "client_user_agent": "Mozilla/5.0 ...",
      "fbp": "fb.1.1791273000000.123456789"
    },
    "custom_data": { "currency": "EUR", "value": 84.50 }
  }]
}

The pixel sends the same purchase with eventID: 'order-10293'. Meta sees the same event name and ID on both, and keeps one. You can send events with your own code, through a server-side GTM tag, through a platform integration, or with Meta's Conversions API Gateway, which Meta offers as a no-code option from Events Manager.

Why it matters in 2026

Browser-only measurement keeps losing coverage, and Meta's delivery system optimises on the events it receives. A well-built Conversions API setup gives Meta more complete conversion data and better customer information for matching. A badly built one does the opposite: double-counted purchases inflate reported ROAS and teach the algorithm the wrong thing.

It is also a common reason to adopt server-side tagging: one server container can feed GA4, Google Ads and the Conversions API from the same event stream.

How to check it

1. In Events Manager, open your dataset and use Test events with a test event code to see server events arrive in real time.
2. For each key event, open its details in the dataset overview and check that it is received from both the browser and the server, and look at what Events Manager reports about deduplication.
3. Compare the event_id in the pixel hit (browser network panel) with the one your server sends. They must be identical strings.
4. Check the Event Match Quality score and which customer information parameters are being received.
5. Review diagnostics in Events Manager for warnings about missing parameters or timestamps.

Common mistakes

• No shared event ID. Pixel and server send the same purchase with different or missing IDs.
• Event names differ. Purchase in the pixel and purchase on the server do not deduplicate.
• Unhashed or badly normalised data. Email not lowercased and trimmed before hashing.
• Stale timestamps. Batch jobs that send events older than 7 days get the whole request rejected.
• Ignoring consent. Server events sent for visitors who declined marketing cookies.

Related terms: enhanced conversions, dataLayer, attribution model, incrementality.