Conversion API Setup: The Guide That Doesn't Waste Your Time

The Conversion API Is Not Optional Anymore. Here Is How to Set It Up.

Meta's Conversion API sends conversion data from your server directly to Meta. No browser. No ad blockers. No iOS restrictions.

In 2026, running Facebook ads without CAPI means you are flying with one eye closed. The pixel alone captures 40-60% of conversions due to ad blockers, iOS App Tracking Transparency (11% opt-in rate), and browser privacy features. CAPI fills the gap.

But most CAPI setups are incomplete. They send the wrong events. They miss critical parameters. They do not deduplicate with the pixel. And they stop at the form fill instead of tracking downstream revenue.

This guide covers the three setup methods, what goes wrong with each, and how to get it right.

If you want the full breakdown on why CAPI matters and how it compares to the pixel, start there. This guide is about implementation.

Method 1: Manual CAPI Setup (The Hard Way)

Manual setup means your development team writes code that sends events to Meta's Conversions API endpoint.

Here is what is involved.

Step 1: Generate a Meta access token. In Events Manager, create a System User and generate a long-lived access token. This token authenticates your server's requests to Meta's API.

Step 2: Build the event payload. Each event needs structured data: event name, event time, event source URL, action source, and user data parameters (email, phone, FBCLID, IP address, user agent). Every user data field must be SHA-256 hashed before sending.

Step 3: Send events via the API. Your backend makes POST requests to Meta's Graph API with the event payload. You need to handle authentication, error responses, rate limits, and retries.

Step 4: Deduplicate with pixel events. If both the pixel and CAPI fire for the same conversion, you get double counting. You need a unique event ID that both the pixel event and the CAPI event share. Meta uses this ID to deduplicate.

Step 5: Test and validate. Use Meta's Test Events tool in Events Manager to verify events are arriving, parameters are correct, and deduplication is working.

Realistic timeline: 2-4 weeks. You need a backend developer. You need QA time. You need to handle edge cases like missing parameters and failed requests.

Who this is for: Large teams with dedicated developers who need full control over every parameter. Ecommerce companies with custom checkout flows. Businesses with unusual data architectures.

The catch: Most manual setups only send 2-3 event types. Lead, Purchase, maybe Add to Cart. They rarely send downstream funnel events because those require CRM integration, which is a whole separate development project.

Method 2: GTM Server-Side (The Middle Ground)

Google Tag Manager Server-Side is the most common CAPI setup method. It puts a server container between your website and Meta.

How it works. Instead of your browser sending events directly to Meta's pixel, events go to your GTM server container first. The server container then forwards events to Meta via CAPI. You configure triggers and tags in the GTM interface.

Step 1: Set up a server container. You need a Google Cloud project (or alternative hosting) running the GTM Server-Side container. This costs $50-150/month depending on traffic.

Step 2: Configure the Meta CAPI tag. In GTM Server-Side, add the Meta Conversions API tag. Enter your pixel ID and access token. Map the event parameters.

Step 3: Set up event triggers. Define which events fire and when. Page views, form submissions, purchases. Each trigger sends the event through the server container to Meta.

Step 4: Map user data parameters. The tag needs email, phone, FBCLID, and other identifiers. Some come from the browser request. Others need to be pulled from your dataLayer or first-party cookies.

Step 5: Configure deduplication. Set up matching event IDs between client-side pixel events and server-side CAPI events.

Realistic timeline: 3-7 days. Faster than manual, but you still need someone comfortable with GTM Server-Side configuration. The hosting setup alone takes a few hours.

Who this is for: Marketing teams with technical operations staff. Agencies managing multiple client accounts. Businesses already using GTM extensively.

The catch: GTM Server-Side still only sees browser-level events. A form submission hits the server container and gets forwarded to Meta. But what about the appointment that gets booked in your CRM 10 minutes later? Or the qualified appointment 3 days later? GTM Server-Side cannot see CRM events. So your CAPI setup sends the same events the pixel would have sent, just more reliably.

That is better than pixel-only. But it is not the full picture. You are still not sending the conversion signals that actually train Meta's algorithm.

Method 3: Automated Platform (The Fast Way)

Automated platforms connect to your CRM and handle the entire CAPI pipeline. Event mapping. Parameter hashing. Deduplication. Downstream events. FBCLID stitching.

This is how Cortana works.

Step 1: Connect your CRM. Cortana integrates with HubSpot, GoHighLevel, Typeform, and other platforms via server APIs. Two clicks. No code.

Step 2: Map your pipeline stages. Cortana automatically maps your CRM pipeline stages to Meta conversion events. Appointment Booked. Qualified. Showed. Purchased. You can customize the mapping and values.

Step 3: Done. Cortana handles everything else. Access token management. Parameter hashing. FBCLID stitching. Deduplication with pixel events. Error handling and retries.

Realistic timeline: 2 minutes. Not an exaggeration. Connect CRM, verify mapping, activate. That is it.

Who this is for: Any business running Facebook ads with a CRM-based sales process. Especially businesses with call funnels, demo funnels, or any pipeline where conversions happen after the browser session ends.

The advantage: Cortana does not just replicate what the pixel does via a server. It sends events the pixel can never see. Downstream CRM events with probability-weighted values. That is the difference between "CAPI setup" and "revenue optimization."

Why Most CAPI Setups Fail (And How to Fix Them)

Having CAPI running is not the same as having CAPI working. Here are the five most common failures.

Failure 1: Missing customer parameters. Meta matches CAPI events to users using hashed email, phone, FBCLID, IP address, and user agent. Most setups only send 1-2 of these. Your Event Match Quality drops below 6. Meta cannot confidently match events to clicks. Your data is unreliable.

The fix: Send every available parameter. Email and phone should come from your CRM (confirmed data, not guesses). FBCLID should be captured on the landing page and stitched to the contact. Cortana does this automatically and consistently hits a 9.3 out of 10 Event Match Quality score.

Failure 2: No deduplication. Both the pixel and CAPI fire for the same event. Meta counts it twice. Your conversion numbers are inflated. Your CPA looks artificially low. You make scaling decisions based on wrong numbers.

The fix: Use a shared event ID for both pixel and CAPI events. When Meta sees the same event ID from both sources, it counts it once. Manual and GTM setups need explicit dedup configuration. Cortana handles deduplication automatically.

Failure 3: No downstream events. Your CAPI sends Lead and maybe Purchase. But the funnel stages in between (qualified, showed, etc.) never get sent. Meta only sees the top and bottom of your funnel. It cannot optimize for the middle.

The fix: Map every meaningful pipeline stage to a conversion event. Each with a probability-weighted value. This gives Meta's Lattice algorithm a rich, multi-stage picture of your funnel. Read the full guide on Meta Conversion API for the event architecture.

Failure 4: No event values. You send events without dollar amounts. Meta knows something happened but not how much it was worth. The algorithm optimizes for event volume, not event value. You get more conversions at lower quality.

The fix: Assign probability-weighted values at each stage. A qualified appointment is worth more than a booked call. A showed appointment is worth more than a qualified appointment. These values train the Lattice algorithm to prioritize high-value profiles.

Failure 5: FBCLID not captured. The FBCLID is the strongest matching signal. It is a direct identifier, not a probabilistic match. If you do not capture it on the landing page, you lose the single best data point for connecting ad clicks to conversions.

The fix: Capture the FBCLID from the URL parameter when the prospect lands on your page. Cortana captures the FBCLID even when the pixel is blocked because it reads the URL parameter server-side. This ID gets stitched to every downstream event.

Event Match Quality: The Number That Matters

Event Match Quality (EMQ) is Meta's 1-10 score that tells you how well Meta can match your CAPI events to Facebook users. Higher EMQ means Meta is more confident in the match. More confidence means better optimization.

Here is the breakdown:

Below 5: Meta cannot reliably match most of your events. Your CAPI data is mostly noise. The algorithm is guessing.

5-7: Partial matching. Some events get matched, some do not. Your optimization is inconsistent. You will see volatile CPAs.

7-8: Good matching. Meta can use most of your data. Optimization works but has gaps.

9-10: Near-perfect matching. Every event gets matched to a specific user and click. The algorithm has full signal clarity. This is where real optimization happens.

Most manual and GTM setups land in the 5-7 range because they are missing parameters or not sending the FBCLID.

Cortana consistently hits 9.3 out of 10 because every event includes: hashed email, hashed phone, the original FBCLID, pixel ID, IP address, user agent, and the event source URL. The priority algorithm cross-references pixel data with server data to create the highest-confidence match possible.

The difference between 6 EMQ and 9 EMQ is not incremental. It is the difference between Meta's algorithm having a blurry photo and a high-definition portrait of your buyer.

What Your CAPI Should Actually Be Sending

Here is the complete event architecture for a call funnel:

Standard events (most setups stop here):

• PageView
• Lead (form fill)
• Schedule (booked call)

Downstream events (this is where the value is):

• Qualified Appointment (with probability-weighted value)
• Showed Appointment (with probability-weighted value)
• Purchase / Closed Deal (with actual transaction value)

Every event should include:

• event_name
• event_time
• event_source_url
• action_source: "server"
• event_id (for deduplication)
• user_data: em (hashed email), ph (hashed phone), fbc (FBCLID), fbp (pixel ID), client_ip_address, client_user_agent
• custom_data: value, currency, content_name

Most setups only send the first three events with 2-3 user data parameters. That is why most dashboards lie about your real numbers. You are feeding Meta incomplete data and then trusting the results.

Cortana sends all six event types with all parameters populated. Every event includes the FBCLID from the original click. Every downstream event includes a probability-weighted value that trains Meta's Lattice algorithm to optimize for revenue.

You can click into any conversion inside Cortana and see the full customer journey. Name, email, phone, every touchpoint from ad click to closed deal. Real attribution data, not modeled estimates.

Set up your CAPI in 2 minutes and start sending real conversion data