Facebook Conversions API Setup: Why Server-Side Tracking Needs a Dataset, System User Token, and — for SaaS Platforms — App Review (2026)
The Facebook Conversions API (CAPI) sends conversion events to Meta from your server instead of the browser. For a single business it is deceptively quick to start — no App Review at all. But the moment you build it into a SaaS product that sends events on behalf of clients, the requirements change completely: App Review, specific permissions, a Facebook representative, and event deduplication that has to be exactly right or your ad reporting quietly breaks.
What the Conversions API actually is
Browser pixel events are like airmail; server events are like freight. Both carry the same package — data about a conversion — to the same destination, your Pixel (now called a dataset) ID. The difference is that CAPI events come from your server, so they survive ad blockers, page abandonment, and the browser changes that increasingly cause pixel-only setups to lose signal.
That reliability is why advertisers and marketing SaaS tools move to server-side tracking. It is also why the setup carries more moving parts than dropping a pixel snippet on a page. If your integration also touches ad data programmatically, our Meta Ads API / Marketing API access guide covers the permission side.
What you need before you send a single event
A dataset (Pixel) ID
You must have a Pixel / dataset ID. If a pixel already fires on the website, reuse the same ID for browser and server events so they can be matched.
A Business Manager
The API runs inside Meta Business Manager. The business, the app, the dataset, and the system user all live under it.
An access token
Every CAPI call passes an access token. It is generated in Events Manager or from your own app plus a system user — the token, not a login, is what authenticates each request.
Correctly formatted parameters
Web events require client_user_agent, action_source, and event_source_url; non-web events require action_source. Customer-information fields must be SHA-256 hashed before they are sent.
Where Conversions API setups go wrong
- The token is generated by the wrong person. In Events Manager the “Generate access token” link is only visible to users with developer privileges for the business. If the person setting it up lacks that role, the link simply is not there — and they assume the feature is missing.
- User tokens used in production. A user access token represents a person and expires, breaking the integration. Server-to-server sending needs a system user token, which never expires — exactly why it exists.
- Duplicate events inflate or corrupt reporting. If you send the same event via both pixel and CAPI without a matching event_id and event_name, Meta counts it twice. Deduplication is not automatic unless those keys line up.
- Unhashed personal data. Email, phone, and other customer parameters must be normalized and SHA-256 hashed. Sending them in plain text fails matching and creates a privacy exposure.
- Outbound firewall blocks. If your server has an outbound firewall, Meta’s IP ranges have to be allowed — and that list changes often, so a setup that worked can silently start dropping events.
- Assuming a SaaS build is the same as a single-business build. It is not. Offering CAPI to your clients pulls you into App Review (see below), which teams routinely discover only after building the whole integration.
How a direct (single-business) setup comes together
Confirm the dataset and Business Manager
One dataset ID, owned by the correct Business Manager, reused across browser and server so events can be matched later.
Generate the access token
Either through Events Manager — which auto-creates a Conversions API app and system user with no App Review — or from your own app by assigning the dataset to a system user and generating a token.
Send events with the right parameters
Required fields, hashed customer data, and a shared event_id on any event also sent via the pixel.
Verify and deduplicate
Check events land with a 200 response, confirm deduplication is working, and tune Event Match Quality.
For a single business sending its own events, that is the whole path — and Meta states plainly there is no need to go through App Review or request any permissions. The details inside each step are where setups stall; this overview is deliberately high level.
The part most teams miss: the platform path needs App Review
Everything above is the direct integration — one business, its own dataset, no review. The moment you build CAPI into a product that sends events on behalf of other advertisers — a website builder, tag manager, CRM, or marketing SaaS — Meta treats you as a platform, and the requirements are different:
- Your app must go through App Review, requesting a specific access level, feature, and permissions.
- You need a Facebook representative engaged with your integration.
- You send a partner_agent identifier on every event so conversions are attributed to your platform — agreed with your Meta representative.
- To send on behalf of clients you either collect a client system user token manually, or use the Facebook Business Extension (FBE) to convert a client’s user token into a system user token with one extra API call.
This is the gap that turns a “quick” CAPI feature into a multi-week submission project. Getting the App Review scope, screencast, and permission set right the first time is exactly the kind of work our Facebook App Review service handles. If you would rather not own the server-side build, you can hire a Facebook API developer who has shipped this before.
Frequently asked questions
Does the Conversions API require App Review?
For a single business sending its own events, no — Meta explicitly says no App Review or permissions are needed. But if you build CAPI into a platform that sends events for other advertisers, your app must go through App Review with specific access and permissions.
What token should I use?
A system user access token. It represents your server rather than a person and never expires, which is what makes unattended server-side sending reliable. User tokens expire and will break the integration.
How does event deduplication work?
Meta matches a pixel event and a server event when their event_id and event_name are identical. If both arrive within about five minutes, the browser event is favored; matching events are deduplicated within a 48-hour window.
Do I have to hash customer data?
Yes. Customer-information parameters such as email and phone must be normalized and SHA-256 hashed before they are sent. Server-only fields like the event timestamp are not hashed.
Facts here are based on Meta’s official Conversions API documentation (Get Started, Parameters, Deduplication, and Set Up as a Platform), reviewed July 2026. This is technical implementation guidance, not legal advice, and is not affiliated with or endorsed by Meta Platforms, Inc. Meta makes all App Review, verification, and enforcement decisions independently; no specific outcome or timeline can be guaranteed. Need your Conversions API or platform App Review handled correctly the first time? Reach out through the contact options in the footer.