Meta Conversions API Setup in 2026: One-Click, Gateway or Server-Side GTM, With Deduplication That Actually Works

The Conversions API is how Meta receives events from your server instead of from the visitor's browser. It exists because browsers lose events: iOS tracking protection, ad blockers, consent declines, and tabs closed before the pixel fires. In accounts I audit, a correctly deduplicated Conversions API setup typically adds a meaningful share of purchases and leads that the pixel alone never reported, and it is the only way to tell Meta about events that happen off the website, such as a lead becoming a customer.

This guide covers the options available in 2026, when to use each, and the full server-side GTM setup with deduplication, user data and consent.

The Four Ways to Send Conversions API Events

Option	Cost	Control	Best for
Meta one-click setup, launched April 2026	Free	None	Small sites with a working pixel and nothing server-side
Conversions API Gateway	Cloud hosting cost	Low	Sites that want server events without a tag manager
Platform integrations such as Shopify's Meta channel	Usually free	Low	Stores happy with the platform's default events
Server-side Google Tag Manager	Hosting from about $20 a month	Full	Anyone who also runs GA4 and Google Ads server-side, or needs CRM events

My default for clients is server-side GTM, because the same container also carries GA4 and Google Ads, and because CRM events such as qualified leads need a place to arrive.

Option 1: Meta's One-Click Setup

In Events Manager, open your dataset, choose Settings, then the Conversions API section, and look for the setup option labelled Set up with Meta. It takes a click, costs nothing and mirrors your browser pixel events server-side with automatic deduplication.

Turn it on if you have nothing else. Turn it off before switching to server-side GTM, or you will send three copies of every event.

Option 2 and 3: Gateway and Platform Integrations

The Gateway deploys a Meta-managed instance in your cloud account that relays browser events server-side. Platform integrations such as Shopify's Facebook and Instagram channel include the Conversions API for the platform's standard events. Both are reasonable if you never intend to run server-side GTM. Neither can send events from your CRM.

Option 4: Server-Side GTM, Step by Step

Step 1: A server container

Create a server container in Tag Manager and host it on a subdomain of your site such as sgtm.yourdomain.com. Google Cloud Run, Stape, Addingwell and similar providers all work; the Server-Side Tracking guide on this site compares them. Point your web container's GA4 and Google tag transport to the server URL so browser events flow through it.

Step 2: Access token and test code

In Events Manager, open the dataset Settings, scroll to Conversions API, and generate an access token under Set up manually. Copy it. In the Test Events tab, note the test event code for verification.

Step 3: Event IDs in the browser

Every pixel event you plan to mirror needs an event_id. Push it in the dataLayer with the event, and use it in both the browser pixel tag and the server tag. For purchases the transaction ID is ideal. For other events generate one:

<script>
(function () {
  function uuid() {
    return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function (c) {
      var r = Math.random() * 16 | 0, v = c === 'x' ? r : (r & 0x3 | 0x8);
      return v.toString(16);
    });
  }
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'event_id_ready', event_id: uuid() });
})();
</script>

Better: generate the ID at the moment of the conversion and include it in the same push as the event, for example form_submit_success with event_id set to form_id + '-' + Date.now().

Step 4: Send events to the server container

If your GA4 tags already route through the server container, the GA4 client there receives every event with its parameters, including event_id, user_email and so on, and server tags can read them. This is the simplest transport: one browser request feeds GA4, Google Ads and Meta on the server.

Step 5: The Meta Conversions API tag on the server

Add the Facebook Conversions API tag template to the server container from the Community Template Gallery. Configure:

• Pixel ID: the dataset ID.
• API access token: from Step 2.
• Action source: website.
• Event name: map GA4 names to Meta names. purchase to Purchase, generate_lead to Lead, add_to_cart to AddToCart, begin_checkout to InitiateCheckout, view_item to ViewContent, page_view to PageView.
• Event ID: the event_id from event data.
• User data: email, phone, first and last name, city, postcode, country from event data, plus client IP address and user agent, which the template reads from the request, and the _fbp and _fbc cookies.
• Custom data: value, currency, content_ids, content_type, num_items, order_id.
• Test event code: your test code while testing, removed before publishing.

Trigger it on the events you chose.

Step 6: Cookies that improve matching

The _fbp cookie identifies the browser; the _fbc cookie carries the click ID from the ad. The server template can set and refresh both as first-party HTTP cookies, which survive longer than browser-set cookies on Safari. Enable that option in the template. Where a visitor arrives with fbclid in the URL and no _fbc cookie, create it in the format fb.1.<timestamp>.<fbclid>.

Step 7: Consent

Pass the consent state from the browser to the server. In the web container, add the consent state as event parameters or rely on Consent Mode signals forwarded by the GA4 client. In the server container, add a trigger condition so the Meta tag only fires, or only includes user data, when advertising consent is granted. Server-side does not remove the need for permission.

Step 8: CRM events the browser never sees

For a qualified lead, a booked appointment confirmed by staff, or a closed deal, send a webhook from your CRM to the server container, parse it with a Client, and fire the Conversions API tag with the hashed email, an event_id built from the CRM record ID, and action_source set to the appropriate value such as system_generated or crm. The HubSpot guide on this site shows the full flow.

Testing

1. Browser: GTM Preview. Confirm each pixel event fires once with an event_id.
2. Server: open the server container Preview. Confirm the incoming event, the Meta tag firing, and the outgoing request body with event_id, user_data and custom_data.
3. Events Manager, Test Events: with the test code set, each conversion should appear twice, once from Browser and once from Server, marked as deduplicated.
4. Remove the test event code and publish both containers.
5. Next day, Events Manager Diagnostics and the dataset Overview should show server events with a healthy match quality and no duplicate warnings.

Common Problems

• Duplicates. Event IDs differ between browser and server, or one-click setup is still enabled alongside server-side GTM.
• Server events but no match. User data missing on the server. Check that email and phone reach the event data and that the template is hashing them.
• Everything arrives, nothing attributes. _fbc not present. Check cookie settings and the fbclid handling.
• Events in Test Events, nothing in reports. Test event code left in the published tag.

Outcome

Meta receives every meaningful event once, from the browser when it can and from the server always, with the identifiers needed to match it to a person. Campaign optimisation improves because the algorithm finally sees the full picture, and your reported purchases stop drifting from your real ones.