How to set up Meta Conversions API server-side tracking

Admaxxer is a marketing analytics and attribution platform for DTC brands and SaaS companies. This guide walks through setting up Meta's Conversions API (CAPI) — the server-to-server way to send purchase and conversion events to Meta — so that your ad optimization keeps working after the browser-side pixel loses signal to ad-blockers, Safari's tracking prevention, and iOS App Tracking Transparency.

The short version: the Meta Pixel fires in the browser and is increasingly blocked; the Conversions API fires from your server and is not. Run both, tie them together with a shared event ID, and Meta merges the two for the best possible match quality. This guide is written for an ecommerce "Purchase" event; if you run a SaaS product, the same mechanics apply — you'll send a "Subscribe" or "StartTrial" / "CompleteRegistration" event instead of "Purchase" (more on that below).

What server-side tracking solves

A browser pixel depends on JavaScript executing in the shopper's browser and a network request reaching Meta. Both can fail: ad-blockers drop the request at the network layer, Safari's Intelligent Tracking Prevention truncates the cookies the pixel relies on, and a slow page can unload before the pixel fires. The Conversions API sidesteps all of this by sending the event from your server, where none of those browser-side failures apply.

The result you should expect is a more complete conversion stream feeding Meta's bidder — which means better optimization, more accurate reported conversions, and stronger lookalike-audience seeds. For the conceptual background on why platform-reported and pixel-reported conversions diverge, see our platform vs pixel conversions guide, and for the wider picture of why this matters post-iOS, read server-side tracking explained.

Prerequisites

Before you wire up the Conversions API, make sure you have:

• A Meta Pixel (now part of a dataset in Meta Events Manager) already created and firing in the browser.
• A verified domain. Meta asks you to verify ownership of your domain in Business settings so it trusts the events tied to it and lets you configure event priority. See Meta's Conversions API documentation for the current setup requirements.
• The ability to send authenticated server-side requests — in practice this means a Conversions API access token generated in Events Manager for your dataset.
• Access to the customer data you'll hash and send (email, phone, and a stable customer identifier).

Step-by-step: connect the Meta Conversions API

Step 1: Create the access token in Events Manager

In Meta Events Manager, open your dataset, go to Settings, and find the Conversions API section. Generate an access token there. This token authorizes your server to post events to that specific dataset. Treat it like a password — it should live in your server's secrets, never in client-side code.

If you connect Meta through Admaxxer, the Meta Ads integration walks you through this paste-token step and stores the credential server-side for you, so you never expose it in the browser.

Step 2: Decide which events to send

For a DTC store, the canonical event is Purchase, sent at order completion with the order value and currency. You'll typically also send InitiateCheckout, AddToCart, and ViewContent for funnel coverage.

SaaS difference: there is no "Purchase" in a SaaS funnel. Map your milestones to Meta's standard events instead — CompleteRegistration for sign-up, StartTrial for a trial start, Subscribe for a paid conversion, and Purchase only if you sell one-time licenses. Send the recurring contract value or first-payment value as the event value so the bidder optimizes toward revenue, not raw sign-ups.

Step 3: Send strong identifiers (the match-rate lever)

Meta matches your server event to a Meta user using the identifiers you include in the event's customer-information block. Per Meta's customer information parameters documentation, these include hashed email (em), hashed phone (ph), a stable customer ID (external_id), the click identifier (fbc), the browser identifier (fbp), and the customer's IP address and user agent.

The single biggest mistake here is sending too few identifiers. Email and phone are the highest-value keys because most Meta users have a verified email or phone on their account. Always include:

• Hashed email — lowercase and trim before hashing with SHA-256.
• Hashed phone — normalize to E.164 (country code, digits only) before hashing.
• A stable customer ID — hashed; this lets Meta join events for the same customer across sessions and devices.
• The real customer's IP address and user agent — captured from the shopper's original request, not your server's. This is the most common implementation bug: a server process sends its own IP and a generic user agent, which is useless for matching.

How well these keys are populated is summarized by Meta's Event Match Quality score and, in plain language, by your match rate. For a deeper explanation of what drives it, see our CAPI match rate glossary entry.

Step 4: Deduplicate against the browser pixel with a shared event ID

You are now sending the same purchase from two places — the browser pixel and your server. Without a shared key, Meta counts both and your purchase numbers double.

The fix is the event_id. Generate one deterministic ID per order (a simple, reliable pattern is the order ID plus the event name) and send the identical event_id on both the browser pixel event and the server event. Meta holds each incoming event for a window — up to 48 hours per Meta's documentation — waiting for its twin, and collapses the matched pair into a single conversion. Send the same event_id on both legs and deduplication just works.

Step 5: Validate with Test Events before you trust the numbers

In Events Manager, open the Test Events tab and fire a real test order. The tool shows you which identifiers Meta received and normalized successfully and whether the browser and server events deduplicated. Check three things:

1. The server event arrives and is attributed to the right event name.
2. The identifiers you intended to send show as "received" (badly hashed values are silently dropped and show as not received).
3. The browser and server events deduplicate rather than double-count.

Only after Test Events looks clean should you compare your Meta-reported conversions against your true order count. Expect them to converge, not match exactly — attribution windows and modelled conversions keep the two slightly apart by design.

Common mistakes

• Leaking the server IP instead of the shopper's IP. Capture the original client IP from the inbound request and pass it explicitly.
• Skipping the shared event_id. This is the difference between honest numbers and double-counted purchases.
• Sending unhashed PII. Meta requires SHA-256 hex; unhashed values are rejected and your match quality looks identical to "field not sent."
• Firing the server purchase twice on retries. Use a deterministic event_id so a retry reuses the same ID rather than minting a new event.
• Forgetting the SaaS mapping. Sending Purchase with a value of 0 for a free-trial start teaches the bidder nothing — send the right event with the right value.

How Admaxxer does this for you

Admaxxer ships Meta Conversions API delivery as part of its server-side tracking, with the high-value identifiers pre-wired, the real customer IP and user agent passed through correctly, and the event_id deduplication contract handled automatically so every browser event and its server twin share one ID. You connect Meta once on the Meta Ads integration page and the conversion stream flows server-side from then on. See pricing for what's included, or browse the documentation for the full setup walkthrough.

FAQs

Do I still need the browser pixel if I have the Conversions API? Yes. Meta's recommended setup is to send the same event both ways — browser pixel and server-side Conversions API — with a shared event_id, and let Meta merge them. The server leg recovers what the browser loses; the browser leg contributes cookies and signals the server may not have. Together they beat either alone.

How long does Meta deduplication take? Meta holds each event for a window — up to 48 hours per its documentation — waiting for the matching event_id from the other leg. If the twin never arrives in that window, deduplication can't happen and both events count, so always send the same event_id on both legs.

What's the most important identifier to send? Hashed email, in most cases, because the vast majority of Meta users have a verified email on their account. Phone and a stable customer ID are close partners. Click and browser identifiers help but are more fragile.

How is this different for a SaaS product? There's no "Purchase." Map your funnel to Meta's standard events — CompleteRegistration, StartTrial, Subscribe — and send the contract or first-payment value so the bidder optimizes toward revenue rather than raw sign-ups.

How do I know it's working? Use the Test Events tab in Events Manager to confirm the server event arrives, the identifiers are received, and the browser and server events deduplicate. Then watch your match quality and your reported-vs-true conversion gap close over the following days.