---
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
published_at: 2026-09-11
last_updated: 2026-09-14
format: Guide
---

# Meta Conversions API: how it works and how to set it up

Meta Conversions API, or CAPI, sends event data from a server, website platform, app, or CRM to Meta. For website conversions, it 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](https://developers.facebook.com/documentation/ads-commerce/conversions-api).

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?

| Question | Meta Pixel | Conversions API |
| --- | --- | --- |
| Where is the event sent from? | JavaScript running in the browser | A server or connected platform |
| What can trigger it? | A page interaction or browser callback | A backend event such as a confirmed purchase |
| What must the implementation coordinate? | Browser consent, event timing and identifiers | Event mapping, permitted customer context and delivery |
| What if both report one purchase? | Send a shared event ID | Use the same event name and ID for the matching server event |

Server delivery gives you another place to report a business event. It does not automatically make the event accurate, create missing customer context, or turn every received event into an attributed conversion. Meta recommends pairing Pixel and CAPI and verifying receipt, freshness, deduplication and matching separately. [Meta setup verification](https://developers.facebook.com/documentation/ads-commerce/conversions-api/verifying-setup).

## 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](https://developers.facebook.com/documentation/ads-commerce/conversions-api/get-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](https://developers.google.com/tag-platform/tag-manager/server-side/intro).

For the underlying event flow, see how [browser and server-side tracking](/definitions/server-side-tagging) work together. For a fuller ownership comparison, see [Plainrouter vs server-side GTM and direct APIs](/compare). If you have already chosen a direct or managed path, use the [CAPI setup guide without GTM](/library/meta-capi-without-gtm).

## 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](https://www.datahash.com/docs/platform-integrations/meta-conversions-api-gateway/).

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](https://stape.io/fb-capi-gateway).

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](https://developers.facebook.com/documentation/ads-commerce/conversions-api/deduplicate-pixel-and-server-events).

For executable examples and retry cases, use the [event ID deduplication guide](/library/meta-event-id-deduplication). 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.
2. **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.
3. **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](/library/server-side-consent).
4. **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.
5. **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](https://developers.facebook.com/documentation/ads-commerce/conversions-api/verifying-setup). 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](/library/meta-capi-missing-duplicate-events) to identify the first failed step.
- **The Pixel fails after React or Next.js navigation:** check [route changes, script readiness and development duplicates](/library/meta-capi-missing-duplicate-events#why-is-facebook-pixel-not-working-in-react-or-next-js).
- **Purchases appear twice:** check [event names, IDs and retries](/library/meta-event-id-deduplication).
- **Click or browser identifiers are missing:** learn [how fbclid, fbp and fbc relate](/library/fbp-fbc). A missing click identifier is not automatically an implementation error.
- **Match quality is low or falling:** use the [Event Match Quality diagnostic guide](/library/meta-event-match-quality).

## 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](/product/signals).

Use the [Signals setup documentation](https://plainrouter.com/docs/signals/overview) to evaluate the installation path, or [create a free account](/register) to begin. If you need a different advertising destination or a broader tagging system, check that requirement before choosing an integration.

## Sitemap

See the full [sitemap](/sitemap.md) for all pages.