--- title: 'Meta Conversions API: how it works and how to set it up' description: 'Understand Meta CAPI and Pixel, choose a direct or managed integration, and verify a purchase event before relying on your conversion reports.' canonical: 'https://plainrouter.com/library/meta-conversions-api' format: Guide published_at: '2026-09-11' last_updated: '2026-10-09' --- # Meta Conversions API: how it works and how to set it up **Facebook server-side tracking uses Meta Conversions API (CAPI) to send event data** from a server, website platform, app, or CRM to Meta. For website conversions, CAPI is commonly used alongside Meta Pixel: the browser reports an event through Pixel and the backend sends the corresponding server event through CAPI. When both describe the same action, they need coordinated deduplication. [Meta CAPI overview](). Start by choosing who will own the integration. Then prove that one real event reaches the intended dataset with the right identity, value, and browser/server pairing. Adding more event types before that check makes failures harder to isolate. ## Meta Pixel and Conversions API: what changes? [Meta Pixel]() reports configured browser events, while Conversions API accepts server-side events from your chosen source. Use both for overlapping web events only with coordinated event names and IDs. Compare [Conversions API vs Meta Pixel]() for what each channel can see and when to use both. ## Does Facebook server-side tracking replace the Pixel? **It changes the delivery path; it does not automatically replace the event source.** A server container can forward an event first collected in the browser. A backend can instead report a confirmed payment directly. Only the second source can report that payment independently of a thank-you page loading. For CRM or in-store purchases, follow the [Meta offline conversions guide]() to check the event source, matching fields and upload timing. For sales completed in a WhatsApp chat, use [click-to-WhatsApp ads and business-messaging conversion tracking]() rather than assuming a website Pixel sees the purchase. | Your event source | Start with | Verify before sending | | --- | --- | --- | | Existing web Pixel events | A supported Pixel-based Gateway or coordinated Pixel/CAPI integration | Which web events it observes, and whether another integration already forwards them | | Backend-confirmed purchase or renewal | Direct CAPI or a managed integration that accepts that backend event | Event identity, time, permitted matching data, value and destination | | Existing GTM data layer | A configured server GTM path | The browser trigger, server client and Meta tag all receive the intended fields | If the same purchase also has a browser copy, coordinate its event name and ID with the server copy. If there is no browser event, do not manufacture one to make a pair. Start with the [CAPI guide without GTM]() for direct and managed paths, or compare [provider event sources and destinations](). ## Choose an implementation method These are ownership choices, not a ranking of tools. Choose the approach your team can maintain and test. | Approach | A useful fit when | Work to plan for | | --- | --- | --- | | Direct Meta API integration | Your application already owns the event source and your developers want control of delivery | Credentials, event mapping, retries, consent context and ongoing monitoring | | Managed integration | You want a supported setup and an operational view of conversion delivery | Verify which events and platforms are supported, how consent is passed, and how errors are exposed | | Server-side Google Tag Manager | Your team already manages a tagging container and needs configurable routing | Operate the server container, configure its clients and tags, and test the chosen Meta integration | Meta documents several integration options and the prerequisites for a direct connection. A direct integration needs the correct Pixel/dataset ID and an access token. Keep that credential server-side. [Meta getting started](). Server-side GTM is a container running on infrastructure you control. It processes incoming data using clients, tags and triggers; it is not itself a ready-made Meta CAPI setup. [Google's server-side tagging introduction](). For the underlying event flow, see how [browser and server-side tracking]() work together. For a fuller ownership comparison, see [Plainrouter vs server-side GTM and direct APIs](). If you want a provider to operate part of the setup, compare [server-side tracking tools by setup, supported destinations, and cost](). If you have already chosen a direct or managed path, use the [CAPI setup guide without GTM](). ## What is a Conversions API system user, and where does its token come from? A Meta system user represents a server or software making API calls to business assets. For a direct Conversions API integration with your own app and system user, Meta’s [getting-started guide]() says to open Business Settings, assign the Pixel to that system user, then select the user and choose Generate Token. Meta also documents an Events Manager path: select the Pixel, open Settings and generate a token under Conversions API → Set up manually. Managing that integration can create a Conversions API app and system user for you. Keep the token on the server; [system users]() are integration credentials, not visitor identities. ## What is Conversions API Gateway? Conversions API Gateway is a specific way to connect website events to Meta CAPI. Hosted options connect an existing Meta Pixel or dataset through a guided setup. For example, Datahash documents a partner-hosted flow that starts from Events Manager or its own console. [Datahash Gateway setup](). Consider Gateway when you want a supported Meta connection without building a direct API client. It is different from a general-purpose server-side GTM container: Stape describes its Meta Gateway as a Meta-only option, while a server container can route to several platforms through configured tags. Check the hosting provider's current scope and requirements. [Stape's Gateway comparison](). Before choosing a hosted Gateway, check: - **Event coverage:** which website events and fields it receives, and how the intended dataset is selected. - **Existing delivery:** whether another plugin, API client, or managed integration already sends those purchases to Meta. Plan one coordinated delivery setup and verify deduplication. - **Permissions and consent:** the access the provider needs and how recorded consent choices govern event delivery. - **Operations and cost:** who monitors failures, what hosting or subscription charges apply, and what happens when a trial ends. A connected Gateway still needs the receipt, freshness, matching, and deduplication checks below. Plainrouter Signals is a separate managed integration; do not assume a Plainrouter setup is a Gateway-hosting service. ## Follow one purchase through the setup Consider a test purchase for **49 EUR**, with the event identifier ` purchase_demo_001 `. The following is a field map, not a complete API request: | Value | Browser Pixel copy | Server CAPI copy | | --- | --- | --- | | Event name | ` Purchase ` | ` Purchase ` | | Event identifier | ` eventID: purchase_demo_001 ` | ` event_id: purchase_demo_001 ` | | Purchase value | ` 49 ` | ` 49 ` | | Currency | ` EUR ` | ` EUR ` | Both copies represent the same purchase. Give another purchase a different identifier. Retrying delivery of this purchase should retain its existing identifier rather than inventing another one. Meta's recommended browser/server pairing uses matching event names and IDs. The browser option is named ` eventID `; the server field is ` event_id `. An ID alone is not evidence that Meta has deduplicated the pair. [Meta deduplication documentation](). For executable examples and retry cases, use the [event ID deduplication guide](). Keeping those details in one guide avoids maintaining several slightly different implementations. ## Verify the result before expanding 1. **Choose one event source.** Decide what confirms a purchase in your application. A thank-you page reload should not become a new business transaction. 1. **Check the destination.** Confirm the integration sends to the intended Meta dataset, including any browser copy. Keep test activity separate from production reporting where your setup supports it. 1. **Pass permitted context.** Use the visitor's recorded consent choices and the appropriate event and customer fields. Server transport does not change the permissions needed to use the data. See the [server-side consent guide](). 1. **Inspect receipt and freshness.** Check Meta's Events Manager, the connection method and the event timing. A request accepted by your integration is not proof that Meta received it. Follow our [Meta Events Manager guide]() to find the dataset and check incoming events. 1. **Inspect pairing and matching.** Check deduplication for browser/server copies. Review Event Match Quality separately; it describes matching context, not whether a purchase was attributed to an ad. Meta documents these verification stages in its [setup verification guide](). Keep a short test record with the event ID, intended destination and observed outcome before enabling more events. ## Troubleshoot the symptom you actually have - **Nothing appears in Meta:** follow [missing Pixel and CAPI events]() to identify the first failed step. - **The Pixel fails after React or Next.js navigation:** check [route changes, script readiness and development duplicates](). - **Purchases appear twice:** check [event names, IDs and retries](). - **Click or browser identifiers are missing:** learn [how fbclid, fbp and fbc relate](). A missing click identifier is not automatically an implementation error. - **Match quality is low or falling:** use the [Event Match Quality diagnostic guide](). ## Where Plainrouter fits Plainrouter Signals is a managed option for consent-aware Meta conversion tracking. It pairs browser Pixel and server CAPI events and exposes delivery outcomes so you can investigate what reached Meta. Destination acceptance, Event Match Quality and attribution remain different measurements. [Plainrouter Signals](). For how Meta now estimates incremental conversions, see [Meta incremental attribution](). Use the [Signals setup documentation]() to evaluate the installation path, or [create a free account]() to begin. If you need a different advertising destination or a broader tagging system, check that requirement before choosing an integration.