Meta CAPI Setup: What You Actually Need to Know

The Meta Pixel is not dead. But running it alone without the Conversions API means you are working with incomplete data, and incomplete data produces bad bidding decisions.

Here is the problem, how CAPI solves it, and what a proper implementation actually looks like.

The iOS 14 Attribution Problem

In April 2021, Apple rolled out App Tracking Transparency (ATT) with iOS 14.5. ATT required apps to ask users for permission to track them across other apps and websites. Facebook's app, like all other apps, had to comply.

The result: a large proportion of iPhone users opted out of cross-app tracking. For Meta, this meant the Facebook Pixel on websites could no longer reliably match browser events back to Facebook users on iOS devices. If someone saw your ad on their iPhone, clicked through to your site, and booked a table, that conversion event often went unattributed because the browser cookie was blocked or the cross-site signal was unavailable.

The practical impact was immediate. Reported conversions dropped, reported ROAS dropped, and CPAs appeared to climb, even in cases where the underlying business performance had not changed. The pixel was missing events it could not see.

How CAPI Solves It

The Conversions API works server-side. Instead of relying on a browser-based pixel to fire when a user completes an action, CAPI sends event data directly from your web server (or via a middleware provider) to Meta's servers.

The path looks like this: user completes a booking, your server receives the confirmation, your server sends an event payload to Meta's API including hashed identifiers (email, phone number, name, IP address), the event name, and a timestamp. Meta receives this on the server level without any dependency on browser cookies, iOS privacy settings, or ad blockers.

CAPI cannot guarantee attribution for every event because matching still requires that Meta can connect the hashed identifier to an account in their system. But it recovers a meaningful portion of the conversions that browser-only tracking loses. In practice, accounts that add CAPI to their existing pixel setup typically see an increase in reported conversions of 15 to 30%, which reflects real events that were always happening but were not being recorded.

Browser Pixel vs CAPI: Why You Need Both

A common misconception is that CAPI replaces the pixel. It does not.

The browser pixel fires in real time, directly from the user's browser. It captures events quickly and sends them to Meta with immediate signal availability for the bidding algorithm. CAPI fires from the server, which introduces a slight delay but captures events the browser misses.

Running both in parallel gives you the most complete picture. The browser pixel catches what it can in the browser context. CAPI catches what the browser misses. Together, the coverage is significantly better than either alone.

This is what Meta calls redundant event sending. They call it redundant because you are sending the same event from two sources. Which brings us to deduplication.

Deduplication

When both the pixel and CAPI fire for the same event, Meta needs to know they represent a single conversion, not two separate ones. Without deduplication, your reported conversion count doubles and your bidding algorithm starts optimising toward inflated data.

Deduplication works through a shared event ID. When the browser pixel fires a Purchase event, it includes a unique event ID. When the server sends the corresponding CAPI Purchase event, it includes the same event ID. Meta sees the matching IDs and counts them as one event.

The event ID needs to be generated at the time the conversion occurs and passed to both the pixel and the CAPI payload. If you are using a middleware provider like a Shopify integration or a third-party CAPI gateway, deduplication is usually handled automatically. If you are implementing CAPI directly, this needs to be built into the implementation.

You can verify deduplication is working in Events Manager. Under the Data Sources section for your pixel, Meta shows event counts and whether deduplication is active. A warning about duplicate events appears if the matching is not working correctly.

The Event Priority List for Restaurants

Not every event needs to be sent via CAPI. Prioritise based on what the Meta algorithm uses to optimise your campaigns.

For restaurant campaigns, the priority order is:

1. Lead / InitiateCheckout: booking started or reservation form opened. This is the primary event for Traffic and Lead objective campaigns.
2. Contact: phone number clicked or contact form submitted. High-value intent signal for restaurants.
3. FindLocation: map or directions link clicked. Tells Meta the user is planning a visit, which is a strong signal for location-based campaigns.
4. ViewContent: menu page viewed. Useful for retargeting campaigns.
5. Purchase (if applicable): if the restaurant processes prepaid bookings or events with payment, this is the highest-value event to send via CAPI.

Send these events in priority order. If your implementation can only handle a subset, get the top two or three right before adding more.

How We Implement It

For restaurant clients, we implement CAPI via the Meta Partner Integration in most cases. The partner integration, available through providers like Shopify, WooCommerce, or booking platform plugins, handles the server-side sending without requiring custom development.

For clients with custom booking systems or those using external reservation platforms that do not offer a native CAPI integration, we use Meta's Conversions API Gateway. The Gateway is a server container Meta provides that sits between the website and Meta's API. It requires hosting setup but removes the need for custom API code.

For clients with developer access and a need for maximum flexibility, we implement CAPI directly using the Meta Conversions API, passing hashed user data alongside the standard event parameters. This approach gives full control over event timing, parameter inclusion, and deduplication logic.

How to Verify It Is Working in Events Manager

After implementation, the Events Manager in Meta Business Suite is where you confirm the setup is functioning correctly.

Go to Events Manager, select your pixel, and click the Events tab. You will see each event type listed with a breakdown of browser events and server events. Events received via CAPI appear under the server column.

The event match quality score is the critical metric. This score (rated Low, Medium, Good, or Excellent) reflects how many of the hashed identifiers in your CAPI payloads Meta was able to match to user profiles. A Good or Excellent score means your payloads are including sufficient customer data for Meta to make the match. A Low score typically means the implementation is not including enough identifier fields, usually because email or phone number is missing from the payload.

Check the test events tool during setup. Under Events Manager, Test Events lets you fire test payloads and see whether they appear correctly in real time. Use this to confirm that event names match, deduplication IDs are present, and match quality parameters are included before switching on live traffic.

CAPI is infrastructure, not a campaign tactic. Get it right once and it improves the data quality of every campaign you run. For restaurants in particular, where the booking process often crosses devices and iOS represents a significant share of the audience, the attribution recovery from CAPI is material. See how we set up the full measurement stack for hospitality clients at our Meta Ads services.