Table of Contents
Meta Conversions API: A Complete Guide for Omnichannel Brands
What's In This Guide
On April 15, 2026, Meta made the Conversions API a one-click setup. No server, no developer, no cost. Meta hosts the infrastructure itself, and you activate it from a button in Events Manager.
For most advertisers, that removed the last excuse. For brands selling through retail and marketplaces, it changed almost nothing, because one-click CAPI covers standard web events only. It does not cover offline conversions. If any of your sales volume happens on a shelf at Target or inside an Amazon order, the easy button doesn't reach it.
So an omnichannel brand needs two things running, not one:
- Web Events: Your DTC traffic, covered by the Pixel plus CAPI. Since April, this is close to free and close to instant.
- Offline and Marketplace Events: Your retail volume, which requires a source of identified buyers and a server-side feed. This is where Brij Signal comes in, and it's the half nobody hands you a button for.
This guide covers:
- What the Conversions API is
- Implementation options in 2026
- Exactly how to send in-store and marketplace purchases (the part that changed materially in 2025)
- How to raise Event Match Quality
- And at each step, what the work looks like if you build it yourself versus automate it with Signal.
What is the Meta Conversions API?
The Meta Conversions API, commonly shortened to CAPI, is a server-to-server connection that sends conversion events directly from your systems to Meta, rather than from a visitor's browser.
The Meta Pixel does its job inside the browser, which means it's exposed to everything happening there: ad blockers, Safari's Intelligent Tracking Prevention, iOS App Tracking Transparency opt-outs, consent gating, and ordinary network failures. A meaningful share of conversions never make it out.
CAPI bypasses the browser entirely. Your server sends the event to Meta's endpoint. Nothing in the browser can intercept it.
That has three outcomes:
- Conversions that were being lost start arriving: This improves both reporting accuracy and the data Meta's optimization models train on.
- You can send events the browser never sees at all: In-store purchases, marketplace orders, phone sales, CRM stage changes, subscription renewals, refunds.
- You control what gets sent: Server-side means deliberate, which is both an advantage and a responsibility.
Key Names, Labels, & Definitions
You'll encounter this product under a lot of labels, and they refer to the same thing:
- Meta Conversions API: The current official name
- Facebook Conversions API / Facebook Conversion API: The legacy name, still widely used
- Meta CAPI, Facebook CAPI, CAPI Meta: Common abbreviations
- Conversions API / Conversion API: Singular and plural are used interchangeably
One naming change does matter in practice: in CAPI contexts you'll see references to a Dataset ID rather than a Pixel ID. Datasets replaced the older separate event-set structures and now consolidate web, app, store, and messaging events under one identifier.
If a setup guide asks for your "pixel ID" for a CAPI integration, it's dated.
Conversions API vs. The Meta Pixel
This is the most common point of confusion, so let's settle it: CAPI does not replace the Pixel, and you should run both. Meta's own guidance is explicit on this.
Meta Pixel
- Runs From: The visitor's browser
- Blocked By: Ad blockers, ITP, ATT, consent gating
- Captures: On-site behavior, including pre-purchase signals
- Can Send Offline Events: No
- Data Richness: Browser context, fbp/fbc cookies, user agent
- Setup Difficulty: Low
Conversions API
- Runs From: Your server
- Blocked By: Nothing in the browser
- Captures: Any event your systems know about
- Can Send Offline Events:
- Data Richness: Whatever you choose to send, including hashed PII
- Setup Difficulty: Low to high, depending on method
They capture overlapping but non-identical signal. The Pixel sees browsing behavior and carries browser identifiers that materially improve matching. CAPI sees everything else and survives conditions that break the Pixel.
The critical mechanic when running both is deduplication. If a purchase fires from the Pixel and also arrives via CAPI, Meta needs to recognize them as one event. It does that by matching event_name plus event_id.
Send the same purchase from both sources with different event_id values and Meta counts two conversions, inflating your reported numbers and corrupting the signal your bidding models learn from. Reported inflation of 30–100% is a documented outcome of mismatched IDs.
Why Signal Quality Matters More Under Andromeda
Meta's ad delivery has changed underneath advertisers over the past 18 months, and it raises the stakes on conversion data specifically.
Meta's Andromeda
Andromeda is Meta's ad retrieval engine. It's the layer that decides which ads are even eligible to be shown to a given person before ranking and auction happen. Announced in December 2024 and rolled out gradually through 2025 and into 2026, it replaced largely heuristic ad selection with a deep neural network.
Per Meta Engineering's own disclosures, it improved ad recall by roughly 6% and ad quality by around 8%.
The practical consequence for advertisers: manual targeting stopped being the lever it used to be. Interest stacks and lookalike layers move performance far less than they did, because the retrieval engine is now better at finding the audience itself. What it needs from you instead is creative diversity and signal density.
Meta & Signal
Signal density is the half you control with CAPI. Advantage+ campaigns and Andromeda are optimization engines, and an optimization engine is only as good as the outcome data it's fed. A brand sending Meta 20% of its purchases is asking a very sophisticated model to optimize toward a systematically biased sample of its customers.
Meta's own launch data for one-click CAPI cited an average 17.8% lower cost per result for advertisers running CAPI versus Pixel-only setups. Treat that as directional. It's a platform-published average across a wide population, not a forecast for your account, but the direction is not in dispute.
Your Five Implementation Options in 2026
The right choice depends almost entirely on whether you need offline events. Hint: If you sell in retail or via online marketplaces, you should be using offline events.
1: Meta Enabled CAPI (One-Click)
Launched April 15, 2026. In Events Manager, under your dataset, there's now an option to have Meta stand up and maintain the server-side infrastructure itself.
Setup runs about a minute: Connect Data → Web → select your dataset → choose to set up with Meta.
Covers: Standard web events (PageView, AddToCart, InitiateCheckout, Purchase, Lead). It inherits your Pixel's standard event configuration and sets matching event_id values automatically, so deduplication is handled.
Doesn't Cover: Offline and in-store events, custom events with bespoke logic, multi-source event routing, sending the same events to other ad platforms.
Important Note: If you already run CAPI through a plugin, a partner, or your own server, do not enable this on top of it. You'll create a second parallel pipeline, and unless the event_id values align, you'll double-count. This is the single most common self-inflicted wound of the 2026 rollout.
2: Platform and Partner Integrations
Shopify, WooCommerce, and most major commerce platforms ship their own CAPI connectors, often tuned to that platform's specifics. These are functionally similar to one-click, occasionally better on field mapping. Same limitation: web events only.
3: Conversions API Gateway
This is a self-hosted server, typically on AWS or GCP, tthat you or an agency provisions. It offers more control than the Meta-hosted option, and it can accept non-Pixel events including CRM, offline, and app data. The trade is that somebody now owns a piece of infrastructure, its updates, and its failures.
4: Custom Server-Side Build
This would be your own implementation against Meta's endpoint. This tier can cover offline purchases, apply custom logic, and route events anywhere.
It's the only option on this list where every one of the rules in the rest of this guide becomes your team's responsibility to implement and maintain: normalization, per-field hashing, action_source logic, dedup schemes, two separate acceptance windows, and a rebuild every time Meta changes something.
It also doesn't solve the harder half. A custom build gives you a pipe. It doesn't give you identified retail buyers to send through it.
5: Brij Signal
Brij Signal is purpose-built for the offline half of this problem. It captures the buyer at the moment of purchase (a QR scan on pack or at shelf, a product registration, a rebate claim, a receipt upload) verifies the purchase, and sends it to Meta as a physical_store conversion event automatically, as each purchase happens.
Everything in the sections below that you'd otherwise engineer is handled: the dataset connection, action_source designation, normalization and per-field hashing (including the fields that must stay raw), order_id deduplication, and both acceptance windows. The May 2025 migration off the deprecated Offline Conversions API was absorbed centrally rather than becoming a ticket in anyone's sprint.
Our Top Recommendation
Our recommendation: Turn on one-click CAPI or your platform connector for web events, and run Signal for retail and marketplace events.
They cover different halves of your volume and don't conflict. One-click handles its own event_id deduplication against the Pixel, and offline events deduplicate separately, so the two feeds sit side by side without double-counting.
What you should not do is pick one and assume it covers you. One-click alone leaves 80% of your sales invisible. That's the whole reason this article exists.
The Anatomy of a CAPI Event
Every event is a JSON payload with four groups of fields.
Event Metadata
- event_name — a standard event where one applies (Purchase, Lead, AddToCart). Standard events plug into Meta's optimization; custom events are more limited.
- event_time — a UNIX timestamp of when the action actually happened, not when you uploaded it. This trips up more implementations than any other single field.
- event_id — your unique identifier for deduplication against the Pixel.
- action_source — where the event occurred. Covered in detail below.
User Data (Match Keys)
This is what determines whether Meta can connect your event to a real person. All PII must be normalized first, then SHA-256 hashed:
- Email (em): hashed
- Phone (ph): hashed
- First / last name (fn, ln): hashed
- Date of birth (db): hashed
- City, state, ZIP, country: hashed
- External ID (external_id): hashed
- fbp / fbc browser cookies: not hashed
- Lead ID: not hashed
- Mobile advertiser ID (madid): not hashed
- Client IP address, user agent: not hashed
Normalize before hashing. Lowercase, trim whitespace, strip formatting, put phone numbers in E.164 format. Hash an unnormalized string and your hash won't match Meta's, and you'll get a silent matching failure rather than an error.
Hashing the wrong fields is the other silent killer. fbp and fbc are Meta's own cookie values — they must arrive raw or matching degrades badly. This is one of the most frequently reported causes of post-migration performance drops.
It's worth being blunt about why this information matters so much: nothing in it produces an error message when you get it wrong. Hash fbp, or skip normalization, or send an unformatted phone number, and Meta accepts the event and quietly fails to match it. Your EMQ drops, your attributed conversions thin out, and there's no alert.
Teams have run months of degraded feeds without knowing. If you're building this yourself, the per-field rules above are worth treating as a checklist someone signs off on rather than something a developer implements from memory. With Signal, this layer is handled: normalization, per-field hashing, and the raw-field exceptions are applied on every event.
Custom Data
- value: a bare number. No currency symbols, no thousands separators.
- currency: an ISO code (USD).
- order_id: your transaction identifier, essential for offline deduplication.
- contents / content_ids: line items, which enable catalog and product-level optimization.
Sending real transaction values rather than a placeholder is what makes value-based bidding function. A hardcoded 1.00 teaches Meta that every customer is worth the same, which is the opposite of useful.
Consent and Privacy Fields
Where you operate in regulated jurisdictions, consent state travels with the event. More on this below.
Sending Offline and In-store Purchases to Meta
This is the section most published guides get wrong, and it's the one omnichannel brands need the most! Let's dig in.
The Standalone Offline Conversions API No Longer Exists
Meta deprecated it in May 2025; Graph API v16 was the final version to support it. The CSV-upload-to-an-offline-event-set workflow that a large number of tutorials still describe is gone. Some advertisers who migrated without adjusting their data model reported drops of up to 70% in accepted events.
Everything now runs through the same Conversions API endpoint as your web events. What distinguishes an in-store purchase is one field.
How to Send Offline Purchase Data to Meta for Optimization
1. Use a dataset, and link it. Datasets replaced offline event sets and consolidate web, app, store, and messaging sources. Link the dataset to the ad accounts you want events to attribute to, in Business Settings. Events sent to an unlinked dataset arrive successfully and credit nothing. It's a failure mode that looks like success in the API response.
2. Set action_source correctly. This is the most consequential field in an offline payload:
- physical_store — in-store and retail purchases
- system_generated — CRM, backend, or system-originated events
- website — web events
- phone_call, chat, email, app, other — as applicable
Send a retail purchase as website and it gets misclassified or rejected outright.
3. Respect two different timing windows. Standard CAPI events require an event_time within 7 days. Critically, if a single event in a batch exceeds that, Meta returns an error for the entire request and processes none of it — one stale row can drop a whole upload. For events marked physical_store, Meta's guidance is to upload transactions within 62 days of the conversion.
4. Deduplicate on order_id. Note an important asymmetry: offline events deduplicate only against other offline events, not against Pixel events. So an in-store purchase and a web purchase by the same person on the same day remain two separate conversions — which is usually correct, since they are two separate purchases.
5. Send fresh, not batched. Because of the 7-day window and the all-or-nothing rejection behavior, a weekly batch upload is genuinely risky. Daily is the manual minimum. Event-level delivery as purchases are verified is better, and removes the window as a concern entirely.
For the full cross-platform version of this — including how Google and TikTok differ — see our guide to offline conversion tracking.
Building This Yourself vs. Brij Signal
The five steps above are the specification. Here's what each one costs in practice.
Manually, you're standing up an export from wherever purchase records live, writing normalization and hashing that respects the raw-field exceptions, mapping action_source per event type, maintaining an order_id dedup scheme, and scheduling uploads that stay inside a 7-day window — knowing that a single stale row rejects the entire batch. Then somebody owns it indefinitely, including the next time Meta reorganizes its ingestion the way it did in May 2025.
With Signal, the event fires when the shopper registers the purchase, so it reaches Meta the same day. The physical_store designation, hashing, dedup, and window compliance are applied automatically, and platform-side migrations are handled once, centrally, instead of by every brand's engineering team in parallel.
The difference that matters most isn't the setup effort; it's the timing. A batch process is structurally at odds with a 7-day window and an all-or-nothing rejection rule. Event-level delivery isn't just less work; it removes an entire class of silent failure.
And the step no build addresses: you still need identified retail buyers. Signal supplies them, which is the actual reason it exists. A pipeline with nothing to send is a solved problem in search of data.
Event Match Quality: The Score That Tells You If It's Working
Event Match Quality (EMQ) is Meta's readout on how well it can connect your events to real people. It appears in Events Manager per event source, scored out of 10.
EMQ is the closest thing you get to a direct diagnostic on identifier quality, and unlike most platform metrics it responds predictably to changes you make.
Rough benchmarks in circulation: Treat anything below 7 as a data problem worth fixing before you evaluate campaign performance. For purchase events specifically, practitioners commonly target 8.8 or above. Verify current guidance in Events Manager, since Meta adjusts these.
What actually moves EMQ, roughly in order of impact:
- Email: The single strongest match key.
- Phone number: Nearly as strong, and additive rather than redundant.
- fbp and fbc where available (web events): Very high match confidence, and free if you're already running the Pixel.
- external_id: A stable customer ID improves matching and helps Meta connect events across sources.
- Name, city, state, ZIP: Smaller individual contributions that compound.
Send every identifier you legitimately have. Match keys are additive; Meta uses whichever combination resolves best. There's no penalty for supplying more.
Where EMQ comes from matters more than optimizing it. A high score built on identifiers a customer volunteered directly is qualitatively different from one built on probabilistic stitching, because the underlying record is actually correct.
This is the structural advantage of a registration-based feed. When a shopper types their own email and phone into a product registration or rebate claim, you're not inferring an identity — you have one, first-hand, attached to a verified purchase. Signal's feeds average a 99.7% match rate for exactly that reason. There's no probabilistic step to lose accuracy in, which is also why offline events sourced this way tend to score higher on EMQ than most brands' web events do.
Brands using Brij Signal are seeing EMQs of 9+, along with 30%+ uplifts in attributed conversions on Meta.
Testing, Diagnostics, and What to Monitor
Most broken CAPI implementations were working when someone last checked. Build the checking in.
Before you go live: Use the Test Events tool in Events Manager to confirm payloads arrive and parse as intended, and the Payload Helper to validate structure against Meta's schema.
In the first week: Watch acceptance rate, not performance. Are events being received? Are any being rejected, and for what? Events Manager diagnostics surfaces rejection reasons, and they're specific enough to act on.
Ongoing, monthly at minimum:
- EMQ per source — a drop usually means an identifier stopped being populated upstream.
- Deduplication rate — if it moves suddenly, event_id alignment has broken.
- Rejected events — silent rejections accumulate, and nothing surfaces them but the diagnostics panel.
- Event volume against your actual order volume — the simplest sanity check there is, and the one most teams never run.
That last point is the honest weakness of a self-built pipeline: it depends on someone remembering. Rejections don't page anyone, EMQ decay doesn't send an email, and a feed that broke in March is often discovered in July. Signal monitors delivery and match quality on its own, which turns a recurring discipline problem into a reporting one.
Privacy and Compliance
CAPI moves personal data server-to-server, which makes it a compliance surface. A few things worth knowing, none of which is legal advice, so be sure to get your own counsel:
Hashing is mandatory for PII, but hashing is not anonymization. A SHA-256 hashed email is still personal data under GDPR and most US state privacy law. Hashing is a security control, not a get-out-of-scope card.
Consent still governs. Server-side delivery is not a consent workaround. Route CAPI events through the same consent state as your client-side tags. In February 2026, a German court found GDPR violations in Meta Business Tools tracking and awarded damages per affected user. This is a signal that server-side implementations are within regulators' scope.
EU signal is materially degraded regardless. Meta's own March 2026 DMA compliance reporting indicated that EU users selecting less personalization generate roughly 90% fewer data signals. If a meaningful share of your volume is European, calibrate expectations accordingly.
The AI Pixel enrichment feature that shipped alongside one-click CAPI on April 15, 2026 automatically extracts product names, prices, and availability from your pages. Existing Pixel users got a 30-day notification window before activation. If you have reason to control precisely what page data reaches Meta, check your Events Manager settings. This may already be on.
Eight Mistakes That Break CAPI Implementations
- Hashing fbp, fbc, lead IDs, or device IDs. These go raw. Hashing them degrades matching with no error message.
- Failing to normalize before hashing. Uppercase, whitespace, or unformatted phone numbers produce hashes that will never match.
- Using upload time as event_time. The timestamp must be the transaction. Get this wrong and you'll breach acceptance windows without realizing.
- The wrong action_source. Retail purchases sent as website get misclassified or rejected.
- Mismatched event_id between Pixel and CAPI. Produces double-counted conversions and corrupts the optimization signal.
- Enabling one-click CAPI on top of an existing integration. Same outcome as #5, at scale, and it's the signature 2026 mistake.
- Placeholder conversion values. Value-based bidding needs real amounts.
- Never returning to the diagnostics panel. Silent rejections compound for months.
Worth noticing what these have in common: seven of the eight are implementation and maintenance errors, not strategic ones. They're the failure modes of hand-built pipelines, and on the offline side, all seven are handled for you when the feed is automated. Mistake #6 is the exception, and it's a decision only you can make: don't stack one-click CAPI on top of an integration you already have.
Brij Solves the Data Gap for Omnichannel Brands
Everything above is achievable with engineering effort. The Meta side of it is well documented and, since April, partly free.
The bottleneck sits upstream. CAPI needs a customer identifier attached to a verified purchase. For a DTC order, checkout hands you both. For a purchase made in a Costco aisle or through Amazon, you have neither: no click ID, no email, no session — and your retail partners are not going to share their customer file.
That's the actual problem, and no amount of API work solves it.
Brij solves it with a mechanism called shelf to signal. A shopper buys your product in retail or on a marketplace. They scan a QR code on pack or at shelf, register the product, claim a rebate, or upload a receipt — identifying themselves directly to your brand in exchange for something they want. Brij verifies the purchase, and Signal sends it to Meta as a physical_store conversion event automatically, as each purchase is verified.
That ordering is the point. Everything covered in this guide — the payload rules, the hashing exceptions, the acceptance windows, the dedup logic — is downstream of having a buyer to send. Signal is the only item on the options list above that addresses both halves: it produces the identified buyer and delivers the compliant event.
Two clarifications worth making:
The same event goes everywhere at once. Google and TikTok Ads receive it through their respective Conversions APIs, and your CRM and email/SMS platform receive it in parallel. One capture, four destinations — which is why acquisition efficiency and customer lifetime value improve together instead of trading off.
The customer stays yours. In a receipt-panel or cashback model, the shopper belongs to the app and you receive anonymized aggregate insight. With Brij, the shopper identifies themselves to your brand — your customer, your data, your CAPI connection. Match rates average 99.7%, because the identifiers come from customers who registered rather than probabilistic matching. Brij is SOC 2 Type 1 compliant, GDPR- and CCPA-aligned, with SHA-256 hashing throughout.
FAQ
What is the Meta Conversions API?
A server-to-server connection that sends conversion events directly from your systems to Meta, instead of from a visitor's browser. Because it doesn't run in the browser, it isn't affected by ad blockers, tracking prevention, or consent gating — and it can send events the browser never sees, like in-store purchases.
Is the Conversions API the same as the Facebook Conversions API?
Yes. Facebook Conversions API, Facebook Conversion API, Meta CAPI, and CAPI all refer to the same product. Meta is the current name; the older labels remain in wide use.
Does the Conversions API replace the Meta Pixel?
No. Meta recommends running both, because they capture overlapping but different signal. The Pixel provides browser context and cookie identifiers that improve matching; CAPI provides durability and access to offline events. Running both requires deduplication via matching event_id values.
Should I use Meta's one-click Conversions API setup?
If you're web-only and don't currently run CAPI, yes — it's free and takes about a minute. If you already have a CAPI integration, no: enabling it creates a second pipeline that can double-count conversions. And if you need offline or in-store events, it won't cover them regardless.
How do I send in-store purchases to Meta?
Through the standard Conversions API with action_source set to physical_store, associated with a dataset that's linked to your ad accounts. The old Offline Conversions API and its CSV upload workflow were deprecated in May 2025.
Can I still upload offline conversions with a CSV?
No. That workflow ended with the May 2025 deprecation. Offline events now flow through the same API endpoint as web events.
What is Event Match Quality and what's a good score?
EMQ is Meta's per-source score, out of 10, for how well it can match your events to real people. Below 7 generally indicates a data quality problem; practitioners often target 8.8 or higher on purchase events. Email and phone move it most, followed by fbp/fbc and a stable external_id.
What's the difference between the Conversions API and a Conversions API Gateway?
The Gateway is a self-hosted server, usually on AWS or GCP, that you or an agency provisions and maintains. It offers more control and can accept non-Pixel events including CRM and offline data. Meta-enabled CAPI, by contrast, is hosted by Meta and covers web events only.
Which fields should I not hash?
fbp and fbc cookie values, lead IDs, mobile advertiser IDs, client IP address, and user agent. Everything else that's personally identifying — email, phone, name, date of birth, address components, external ID — must be normalized and then SHA-256 hashed.
How far back can I send an event?
Standard events need an event_time within 7 days, and one over-age event causes Meta to reject the whole request. Events marked physical_store should be uploaded within 62 days of the transaction. Confirm current limits in Meta's documentation before building.
If I turn on one-click CAPI, do I still need something for retail sales?
Yes. One-click covers standard web events only; it has no path to an in-store or marketplace purchase. Omnichannel brands generally run both: one-click or a platform connector for web events, and a dedicated offline feed like Brij Signal for retail and marketplace events. The two don't conflict, since offline events deduplicate separately from Pixel events.
Should I build the offline CAPI feed myself or use a platform?
Building it is feasible if you have engineering capacity and an existing source of identified retail buyers. Most brands have neither. The API work is a few weeks; the maintenance is permanent, the failure modes are silent, and none of it solves the upstream problem of getting a customer identifier attached to a shelf purchase in the first place. That last part is what Signal exists to do.
Does CAPI improve performance or just reporting?
Both, on different timelines. Reporting improves immediately as previously lost conversions arrive. Optimization improves over subsequent weeks as Meta's models train on a more complete picture. Meta's own launch data cited an average 17.8% lower cost per result for CAPI advertisers versus Pixel-only — a population average, not a forecast for any individual account.
The Takeaway
The Meta Conversions API stopped being a technical hurdle in April 2026. For web events, it is now genuinely just a button to turn on.
What didn't change is the harder constraint. CAPI is a delivery mechanism. It moves data you already have, and it cannot conjure a customer identifier for a purchase that happened in an aisle where you had no presence, no session, and no relationship.
So the honest answer for an omnichannel brand is two feeds, not one. Click the button for your DTC traffic. For the retail and marketplace volume that makes up most of your business, you need something that creates the identified buyer and delivers the event automatically, inside the acceptance window, with the hashing rules applied correctly on every record.
That's what Signal does. The CAPI half of this guide is the part you can now get for free. The other half is the one that decides whether Meta ever sees the majority of your sales.
See how Brij turns shelf and marketplace purchases into Meta Conversions API events automatically — book a demo.
