Meta Conversions API (CAPI): The Must-Have Parameters and Events, Why Each Matters to the Algorithm, and How to Set Them Up

Key Takeaways

• Four fields are required on every server event — event_name, event_time, action_source and user_data — and website events also need event_source_url and client_user_agent.
• Matching is the whole game: hashed email and phone, external_id, IP address, user agent, fbc and fbp are what let Meta tie a server event to a real person and an ad.
• Purchase events without value and currency teach the algorithm that every sale is worth the same, which breaks value-based bidding.
• If you send the same event from the pixel and the server, both copies need the same event_name and event_id, or Meta counts the conversion twice.
• Hash contact data with SHA-256 after normalising it; never hash IP address, user agent, fbc, fbp or lead_id.
• The events you send define what the algorithm can optimise for — send the down-funnel ones (qualified lead, purchase) and not just page views.

The Short Answer: What Every CAPI Event Must Carry

The Meta Conversions API lets your server send conversion events to Meta directly, rather than relying only on the pixel in a visitor's browser. That matters because browsers increasingly block or limit the pixel, and because the most valuable events — a qualified lead, a closed sale, a delivered order — usually happen on your server or in your CRM, where no pixel exists. But sending an event is not the same as sending a useful one. Meta's delivery system does three things with every event it receives: it tries to **match** the event to a person on Facebook or Instagram, it tries to **attribute** that person's action to an ad they saw or clicked, and it **learns** from the pattern of who converts so it can find more of them. Each of those steps depends on specific fields in the payload.

Here is the minimum, in one place. Every server event must carry `event_name`, `event_time`, `action_source` and a `user_data` object containing at least one customer information parameter. Website events must also carry `event_source_url` and, inside user_data, `client_user_agent`. Meta's documentation states that `event_time` can be at most seven days old, and that a single event older than that causes the entire request to fail. If you send the same conversion from the pixel and the server — the recommended setup — each copy needs the same `event_id`. Purchase events need `value` and `currency` in `custom_data`.

That minimum gets events accepted. It does not get them matched, attributed or learned from well. The difference between a CAPI setup that merely works and one that improves cost per result is almost entirely in the recommended parameters: the customer information that raises match rates, the browser identifiers that connect events to ad clicks, and the custom data that tells Meta what each conversion was worth. The rest of this guide goes through every one of them. If you need the architecture and setup steps first, start with our Conversions API setup blueprint; this guide is the parameter-level reference that sits alongside it.

Why Parameters Decide How Well Meta's Algorithm Performs

It helps to picture what happens after your server sends an event. Meta receives a payload that says, in effect, “someone with these characteristics did this thing, at this time, on this page, and it was worth this much.” Before that event can influence delivery, Meta has to answer a question: who was it? If it can confidently match the event to an account, it can check whether that person saw or clicked one of your ads within the attribution window, credit the right ad, and add the person to the pool of converters it learns from. If it cannot match the event, the conversion still happened in your business, but for optimisation purposes it barely exists.

That is why Event Match Quality — the 0-to-10 score Events Manager shows for each server event — matters so much. It reflects how many useful customer identifiers you are sending and how well they match. Low match quality means a large share of your conversions are invisible to the algorithm, so it optimises on a thinner, less representative sample. In practice that shows up as higher cost per result, slower exit from the learning phase and less stable delivery, especially at higher budgets.

Parameters also shape what the algorithm optimises **for**. If your Purchase events have no value, value-based bidding has nothing to work with and every order looks equal. If your lead events do not distinguish a junk form fill from a qualified lead, the system learns to find more of whatever is cheapest to generate. And if browser identifiers like fbc are missing, Meta may not be able to link a server-side conversion to the specific click that caused it, weakening attribution precisely for the ads that worked. Every section below follows the same pattern: what the field is, what Meta does with it, what breaks without it, and how to send it.

Required Server Event Parameters: The Fields Every Event Needs

These parameters sit at the top level of each event in the `data` array of a Conversions API request. Get any of them wrong and the event is rejected or misattributed.

**event_time** deserves extra care. Use the time the action actually happened, not the time your server got round to sending it. If you batch events or send CRM updates later, keep the original timestamp. For website events, send in real time or near it; delays reduce Meta's ability to use the event for optimisation even inside the seven-day limit.

**action_source** is often set carelessly. A lead captured on your website is `website`. A sale closed by phone after a website enquiry is `phone_call` or `system_generated` depending on how it was recorded. A conversion from a click-to-WhatsApp conversation uses `business_messaging`. Meta asks that it be accurate to the best of your knowledge, because it changes how the event is treated in attribution.

**event_source_url** should be the real page URL, including the domain you verified in Business Manager. Sending a placeholder or your homepage for every event weakens Meta's ability to connect events to the browsing session and can trigger domain warnings.

Customer Information Parameters: The Fields That Decide Match Quality

The `user_data` object is where match quality is won or lost. Meta can use many identifiers; you should send every one you legitimately have and are permitted to share. The table shows each parameter, whether it must be hashed, and how much it typically contributes to matching.

The highest-impact combination for most websites is **email, phone, external_id, fbc, fbp, IP address and user agent**. Email and phone are the strongest personal identifiers; fbc and fbp connect the event to the browser session and the ad click that started it; IP and user agent provide supporting context Meta uses for matching and for website-event validity. Name and location fields help when email or phone are missing but add less when they are present.

Only send what you collected lawfully and have consent to share. In regions with consent requirements, gate the Conversions API on the same consent signals as your pixel, and use `data_processing_options` where US state laws apply. Sending more identifiers is good for performance only when it is also compliant; the fix for a low match score is to capture identifiers properly, not to share data you should not.

How to Normalise and Hash Customer Data Correctly

Hashing protects personal data in transit: Meta compares your SHA-256 hash with hashes of the data it holds, so the raw value never needs to be sent. But a hash only matches if the input was formatted exactly the way Meta formats it. One stray capital letter or space produces a completely different hash and a failed match. This is the single most common cause of poor match quality we find in audits — our CAPI troubleshooting guide covers the diagnosis.

Three rules prevent most errors. First, normalise, then hash — never hash and then lowercase. Second, hash with SHA-256 and send the lowercase hex digest. Third, do not hash fields Meta asks you not to hash: IP address, user agent, fbc, fbp and lead_id must be sent as raw values, or Meta cannot use them. If you use a partner integration or a server-side Google Tag Manager template, check its documentation: most hash automatically, which means you must send them raw, not pre-hashed, or they will be hashed twice.

Phone numbers are where Indian, UAE and other non-US advertisers lose the most matches. Forms that accept a 10-digit mobile number without the country code produce hashes that will never match, because Meta expects the international format. Add the country code on your server before hashing, based on the form's country field or your market.

fbc and fbp: The Browser Identifiers Most Setups Get Wrong

If email and phone tell Meta **who** converted, fbc and fbp tell it **which session and which click** led there. They are the bridge between your server event and the ad that earned it, and they are frequently missing or malformed.

**fbp** is a first-party cookie the Meta pixel sets on your domain (`_fbp`). It identifies the browser. Read it from the request cookies on your server and pass it through unchanged. **fbc** represents the click. When someone arrives from a Meta ad, the URL contains an `fbclid` parameter, and the pixel stores it in the `_fbc` cookie in the format `fb.1.<creation time in milliseconds>.<fbclid>`. On your server, read `_fbc`; if it is absent but the landing URL contains fbclid, construct the value in that format yourself. Do not send the bare fbclid as fbc.

Two practical problems break fbc in most stacks. The first is that people browse several pages before converting, and the fbclid lives only in the landing URL — if the pixel was blocked or slow, the cookie may never be set. Capture fbclid on landing and persist it in your own first-party cookie or session. The second is that conversions often happen later on the server — a payment webhook, a CRM status change — where no browser cookie is present. Store fbc and fbp with the order or lead record at the moment of submission, so the later server event can include them.

For lead generation, store fbc, fbp, IP address and user agent on the CRM record at form submission. When the lead later qualifies or closes, your CRM event can carry the same identifiers as the original website event, which dramatically improves the chance Meta connects the outcome back to the ad. We explain the CRM side in our guide to choosing a CRM for the Conversions API.

Custom Data Parameters: Telling the Algorithm What a Conversion Was Worth

The `custom_data` object describes the conversion itself. For value-based optimisation and catalogue ads, it is as important as matching.

Decide what value means and stay consistent. For e-commerce we recommend the product subtotal after discounts, excluding tax and shipping, so reported ROAS reflects revenue that matters to margin — we explain why in why ad platform sales don't match your store revenue. For lead generation, assigning values to lead stages — for example a qualified lead worth more than a raw enquiry — lets you use value optimisation even without online sales.

Catalogue advertisers must make content_ids match the IDs in the product catalogue exactly. A mismatch between the pixel's IDs, the server's IDs and the catalogue's IDs is the most common reason dynamic product ads underperform after a CAPI migration.

event_id and Deduplication: Sending From Pixel and Server Without Double Counting

Meta recommends running the pixel and the Conversions API together — the redundant setup — because each catches conversions the other misses. That only works if Meta can tell when two events describe the same action. It does this with two fields: `event_name` and `event_id`. When a browser event and a server event share the same event name and event ID, Meta keeps one and discards the duplicate, provided they arrive within Meta's deduplication window — Meta documents this window as 48 hours.

1. **Generate one ID per action** at the moment it happens — for a purchase, the order ID works well; for a lead, a UUID created when the form is submitted. 2. **Pass it to the pixel** as `eventID` in the fbq call: `fbq('track', 'Purchase', {...}, {eventID: 'ORD-10492'})`. 3. **Pass it to the server** as `event_id` on the Conversions API event. 4. **Use identical event names** on both sides — `Purchase` and `Purchase`, not `Purchase` and `purchase` or `Order`. 5. **Check Events Manager**, which reports deduplication for each event; a high share of events received from both sources with deduplication working is the goal.

Without event_id, the redundant setup double counts. Reported conversions rise, cost per result looks better than reality, and the algorithm learns from inflated signals. If you have seen platform conversions suddenly jump after installing a CAPI integration, missing deduplication is the first thing to check. Our step-by-step guide to fixing CAPI duplicate events walks through the diagnosis.

The Events to Send: E-commerce, Lead Generation and Messaging

Parameters make events useful; the choice of events decides what Meta can optimise for. Meta supports a list of standard events — use them wherever they fit, because standard events are understood by delivery, reporting and catalogue features in ways custom events are not.

**E-commerce.** The essential set is ViewContent, AddToCart, InitiateCheckout and Purchase, all with consistent content IDs and Purchase with value and currency. Send Purchase from the server when the order is confirmed — ideally from your order webhook — so it fires even when the customer pays through an app or never returns to the thank-you page. **Lead generation.** Lead on submission is the floor, not the ceiling. The events that transform lead-gen performance are the ones that happen after submission: qualified lead, appointment booked, opportunity, sale. Sending these back lets Meta optimise for the leads your sales team wants rather than the cheapest form fills, which is exactly the lever we describe in optimising Meta lead ads for qualified leads with CAPI. **Click-to-WhatsApp and messaging.** Conversations that become leads or purchases can be sent through the Conversions API for Business Messaging, covered in the next section.

CRM and Lead-Ad Events: Optimising for Qualified Leads

For businesses that sell through a sales team, the most valuable CAPI events never happen on the website. They happen in the CRM: a lead is qualified, a meeting is held, a deal is won. Meta's Conversions API for CRM is designed for exactly this, and the parameter rules are a little different.

- **Identifier:** For leads that came from Meta instant forms, send the Meta `lead_id` — Meta's documentation makes it the top-priority identifier and rejects invalid lead IDs. For website leads, send hashed email and phone plus the fbc, fbp, IP and user agent you stored at submission. - **event_source:** CRM events for Meta's Conversion Leads optimisation use `crm` as the event source, per Meta's payload specification. - **event_name:** Use your lead stages consistently (for example a qualified-lead stage and a converted stage) and map them in Events Manager. - **event_time:** The time the stage changed in the CRM, sent promptly. - **action_source:** `system_generated` is typical for CRM stage changes.

Once enough qualified-stage events flow, Meta's Conversion Leads optimisation goal for instant-form campaigns can optimise toward the leads that reach those stages instead of raw submissions. For website-based lead generation, the same events enable value rules and custom conversions built on qualified outcomes. Either way, the parameter discipline is what makes it work: without a reliable identifier on every CRM event, Meta cannot connect the qualified outcome back to the original lead and the ad behind it.

A practical tip: change the optimisation event on a new ad set rather than editing a working one, because changing the optimisation event resets learning. And remember that qualified events lag submissions by however long your sales team takes to qualify, so judge results over weeks, not days.

Click-to-WhatsApp: The Conversions API for Business Messaging

Click-to-WhatsApp campaigns send people from an ad straight into a WhatsApp conversation, so there is no website and no pixel. To tell Meta which conversations became leads or sales, you send events through the Conversions API for Business Messaging, and the parameter set is specific.

The `ctwa_clid` arrives in the referral object attached to the first inbound message of a conversation started from a click-to-WhatsApp ad. Your WhatsApp Business Platform integration or provider must capture it when the conversation begins and store it against the contact, so that when the conversation later becomes a qualified lead or a sale, the event can carry it. Meta also notes that it does not deduplicate business messaging events for you, so your system must avoid sending the same outcome twice.

This is the foundation for running click-to-WhatsApp ads on lead quality rather than conversation volume. We cover the full strategy in our guide to generating qualified leads from click-to-WhatsApp campaigns.

Worked Example: Auditing a Purchase Payload (Illustrative)

The easiest way to see the difference parameters make is to compare a payload that works with one that performs. The example below is illustrative, but it is typical of what we find when auditing a D2C store's server-side Purchase event. Here is the payload as we found it:

{
  "event_name": "purchase",
  "event_time": 1761998400,
  "action_source": "website",
  "user_data": {
    "em": "Priya.S@Example.com",
    "ph": "9876543210"
  },
  "custom_data": { "value": 1260 }
}

It is accepted, but it has seven problems. The event name is lowercase, so it will not deduplicate with the pixel's `Purchase`. There is no event_id, so even with matching names the two copies would double count. Email is not normalised or hashed, and the phone has no country code, so neither will match. There is no fbc, fbp, IP address or user agent, so the event cannot be tied to the browser session or the ad click — and as a website event it is missing the user agent and event_source_url Meta requires. There is no currency. And the value of 1,260 includes GST and shipping on a ₹1,000 product.

The corrected payload:

{
  "event_name": "Purchase",
  "event_time": 1761998400,
  "event_id": "ORD-10492",
  "action_source": "website",
  "event_source_url": "https://store.example.com/checkout/thank-you",
  "user_data": {
    "em": ["<sha256 of priya.s@example.com>"],
    "ph": ["<sha256 of 919876543210>"],
    "external_id": ["<sha256 of customer 88213>"],
    "fbc": "fb.1.1761990000000.IwAR...",
    "fbp": "fb.1.1761900000000.123456789",
    "client_ip_address": "203.0.113.24",
    "client_user_agent": "Mozilla/5.0 (Linux; Android 14) ..."
  },
  "custom_data": {
    "value": 1000, "currency": "INR", "order_id": "ORD-10492",
    "content_type": "product", "content_ids": ["SKU-221"],
    "contents": [{ "id": "SKU-221", "quantity": 1, "item_price": 1000 }]
  }
}

Changes like these routinely move a store from a weak match score to a strong one, end double counting and make ROAS comparable to real revenue. None of them change a single campaign — they change what the campaign learns.

Offline, Phone and App Events: Parameters Beyond the Website

Not every conversion happens on a website, and the Conversions API handles the others too. The required set is the same — event_name, event_time, action_source and user_data — but some recommended fields change.

**Physical store and offline sales.** Use `action_source: physical_store`. There is no browser, so fbc, fbp, IP and user agent do not apply; matching relies on the hashed email, phone, name and address you collected at checkout or through a loyalty programme. Meta's offline events documentation highlights external_id as highly recommended. The quality of offline matching depends almost entirely on how consistently store staff capture an email or mobile number. **Phone and chat sales.** A sale closed by phone after an enquiry uses `phone_call`; one closed in a live chat uses `chat`. Reuse the identifiers stored with the original lead — especially fbc and fbp from the website visit — so Meta can connect the eventual sale to the ad that started the journey. **App events.** Mobile apps typically send events through Meta's SDK or a mobile measurement partner, with `action_source: app` and app-specific fields for server events. If you send app events from your server, follow Meta's app-specific parameter requirements carefully, because app attribution follows different rules.

Across all of these, the principle is identical: capture identifiers at the first touch, store them with the customer record, and attach them to every later event about that customer.

Consent, Privacy and Data Processing Options

Sending more customer information improves matching, but only data you collected lawfully and are allowed to share should ever be sent. Three practical rules keep a CAPI setup both effective and compliant.

- **Use the same consent gate for server and browser.** If a visitor declines marketing cookies, your server should not send that visitor's events as if they had accepted. Many setups gate the pixel and forget the server. - **Use data_processing_options where US state privacy laws apply.** Meta's Limited Data Use option lets you flag events from users in regulated states so Meta processes them accordingly. - **Minimise.** Send identifiers that improve matching; do not send unrelated personal data in custom_data, and never send sensitive categories such as health conditions in event names or parameters. This is also an ad policy risk for healthcare and finance advertisers.

In India, the Digital Personal Data Protection Act makes consent and purpose limitation explicit obligations, and in the UAE and EU similar rules apply. Treat compliance as part of the parameter design, not a later legal review: decide which identifiers you collect, on what basis, and how they flow to Meta, and document it.

How to Set Up CAPI Parameters Step by Step

Whichever route you use — a platform integration such as Shopify's Facebook and Instagram channel, a partner like a CDP, server-side Google Tag Manager, or direct API calls from your backend — the setup checklist for parameters is the same.

1. **Map your events.** List the conversion actions that matter, choose the standard event for each, and decide which are sent from the browser, the server or both. 2. **Capture identifiers at the source.** On every form and checkout, capture email and phone (with country code), your customer ID, and read `_fbp`, `_fbc`/fbclid, IP address and user agent on your server. Persist click IDs from the landing page. 3. **Store them with the record.** Save the identifiers on the lead or order so later server and CRM events can reuse them. 4. **Normalise and hash** contact fields exactly as described above, unless your integration does it for you. 5. **Generate event IDs** and pass the same one to pixel and server for any event sent from both. 6. **Populate custom_data**: value and currency on Purchase and valued events; content IDs that match the catalogue. 7. **Send promptly** with the true event_time. 8. **Test** with the Test Events tool in Events Manager using a test event code, then remove it. 9. **Monitor**: Event Match Quality per event, deduplication, and the diagnostics tab for warnings.

If you run server-side Google Tag Manager, our server-side tracking guide covers the tagging architecture. If you prefer a team to build and maintain it, our Conversions API service starts with exactly this parameter audit.

How to Check Your Setup: Event Match Quality and Diagnostics

Once events are flowing, Events Manager gives you most of what you need to judge whether the parameters are doing their job.

- **Event Match Quality (EMQ):** shown per server event on a 0-to-10 scale, with a breakdown of which customer parameters are present and what share of events carry each. Use it to find missing fields, not to chase a number for its own sake. - **Deduplication:** for events sent from both sources, check that a large share are received from both and that deduplication is reported as working. - **Event coverage and freshness:** compare server event counts with pixel counts and look at how quickly server events arrive after they happen. - **Diagnostics:** warnings about invalid parameters, unverified domains, missing currency, mismatched content IDs and similar issues. - **Test Events:** for any change, send a test event and inspect the received payload.

Then reconcile with reality. A good EMQ does not guarantee correct counts; duplicate events or wrong values can co-exist with excellent matching. Once a month, compare Meta's reported conversions with your CRM or store at record level, as we describe in why ad platform leads don't match your CRM. If you would like a quick view of how much signal your account is losing, our free tracking audit checks exactly these parameters.

If You Can Only Fix Three Things: Prioritising CAPI Improvements

Few teams can rebuild their tracking in one sprint. When we audit an account and the list of issues is long, we prioritise by one question: which fix changes what the algorithm learns, rather than just what the report shows? That produces a consistent order.

1. **Stop double counting and fix value.** Shared event IDs between pixel and server, identical event names, and a correct value and currency on Purchase. Inflated or valueless conversions actively mislead optimisation, so they come first even though they rarely show up as a warning. 2. **Raise matching on your most important event.** For most businesses that is Purchase or the qualified-lead stage, not PageView. Add properly normalised email and phone with country code, external_id, and the fbc and fbp values stored at the moment of conversion. Improving match quality on the event you optimise for is worth far more than perfecting an upper-funnel event. 3. **Send the down-funnel event.** If you sell through a sales team or deliver cash-on-delivery orders, the event that represents money in the bank — qualified lead, closed deal, delivered order — is the single most valuable addition you can make. It changes what Meta is trying to find.

Everything else — richer product data, additional standard events, name and address fields, finer custom data — is worthwhile, but it is refinement. A team that does these three things well will usually see a bigger improvement than one that sends every optional field on every event but still double counts purchases or optimises for raw form fills.

Measure the effect properly. Change one thing at a time where you can, note the date, and compare cost per real outcome in your CRM or store over the following weeks rather than reading Ads Manager alone, since several of these fixes deliberately lower reported conversions while improving real ones.

Common CAPI Parameter Mistakes and How to Fix Them

Most accounts have two or three of these at once. Fix them in order of impact: deduplication and value first, because they distort what the algorithm learns; then matching fields; then event coverage.

Why This Is Crucial in 2026

Two changes make clean CAPI parameters more important now than at any point since the Conversions API launched. First, Meta's delivery has shifted toward broad, Advantage+-style targeting in which the algorithm, guided by your conversion signal and your creative, decides who sees each ad. In that world, the conversion signal is one of the few levers advertisers still control, and a thin or noisy signal translates directly into worse targeting. Second, measurement has narrowed: during 2026 Meta changed which conversions Ads Manager attributes, as we cover in Meta conversions after the 2026 attribution changes. Every conversion you can match and attribute accurately now counts for more.

The businesses that benefit most are those whose real conversions happen away from the browser: lead generation with a sales cycle, cash-on-delivery e-commerce, subscriptions, and click-to-WhatsApp. For them, the server events — qualified lead, delivered order, closed deal — are the difference between an algorithm that chases cheap actions and one that finds customers. Getting the parameters right is not an IT task to tick off; it is the most direct way to improve what Meta learns about your best customers.