Meta Conversions API (CAPI)

Enhance your tracking reliability and ensure accurate conversion data with our server-side integration for Meta (Facebook) via the Conversions API (CAPI).

Server-side tracking requires an active Growth or Business plan.

The optional browser event works on every plan — only the server-side conversion needs the Growth or Business plan.

Check our pricing page for more details.

Browser-side tracking—such as the standard Meta Pixel—is increasingly limited by ad-blockers, browser privacy features (like ITP), and user cookie settings. This can lead to significant data loss and inaccurate campaign reporting.

Our Meta CAPI integration solves this by sending your conversion events directly from our servers to Meta.

Capture conversions even when users employ ad-blockers or privacy-focused browsers, ensuring no event goes untracked.

Higher data quality allows for more accurate conversion attribution and better optimization of your Facebook ad campaigns. We automatically capture and send _fbp and _fbc cookies (only if we have the necessary consent), IP Address, User Agent, and Page URL to maximize Meta's Event Match Quality (EMQ). If the _fbc cookie is missing, we build it from the fbclid URL parameter of the visitor's landing page.

Every form submission gets a unique Event ID — you can see it in the branchside_form_submission data layer event. When both the browser and our servers track the same submission, Meta uses this ID to deduplicate the events and prevent double-counting.

Both sides must use the same Pixel. Branchside does not load the Meta Pixel for you — whatever Pixel your page loads is the one that receives the browser event. If your page loads a different Pixel than the one selected for server-side tracking, Meta treats the events as unrelated.

• Consent-Aware: Server-side events follow the consent state of each submission. ad_storage consent is required before anything is sent to Meta, and hashed customer data is only included when the visitor also granted ad_user_data consent. The browser event (fbq) is different: it only fires if the Meta Pixel is loaded on your page, so its consent handling is the site owner's responsibility — Branchside never installs the Pixel base code for you.

• Secure Transmission: Data is sent directly from our secure servers to Meta, minimizing the surface area for tracking interference and ensuring the integrity of your data.

1. Event Collection: When a user submits your form, we securely capture the necessary conversion metadata alongside user consent status.

2. The data layer push: Every successful submission pushes a branchside_form_submission event to your window.dataLayer, containing the form ID and a unique Event ID. This happens on every plan, whether or not you have configured any conversion.

3. The optional browser event: If you turned on the "Browser event:" toggle for your Facebook conversion, we call fbq("track", ...) in the visitor's browser after the form is submitted. The Pixel must already be loaded on your page by your own setup.

4. The consent check: Before anything leaves our servers, we verify the consent state. Server-side dispatch requires at least ad_storage consent.

5. Secure Server-to-Server Transfer: Alongside browser events, our platform securely sends this event data directly to Meta's Conversions API.

6. Accurate Reporting: Meta receives the verified event, allowing you to track conversions reliably within your Meta Ads Manager.

Our platform integrates seamlessly with the Google Consent Mode v2 standard. We automatically inspect the window.dataLayer on your site.

For server-side tracking events to be dispatched to Meta, the user must have granted consent for at least ad_storage. If ad_storage consent is missing or denied, no server-side events are sent. To include Personally Identifiable Information (PII) with the event data, the user must also grant ad_user_data consent.

How the two consent settings affect each tracking path:

With ad_storage granted, every server-side event includes:

• The visitor's IP address and user agent, as seen by our servers.

• The _fbp cookie, and _fbc when present — if the _fbc cookie is missing, we build it from the fbclid URL parameter.

• The full page URL and referrer.

With ad_user_data granted, the event additionally includes your mapped fields hashed (SHA-256) — email, phone, first name, last name, city, state, zip and country.

Branchside does not install the Meta Pixel base code and does not control when it loads. The browser event only fires if the Pixel is already loaded on your page. If you use a consent banner, load the Pixel only after the visitor grants ad_storage consent. Server events also require ad_storage consent. Load the Pixel under the same condition: if the Pixel loads without it, the browser event fires with no matching server event and Meta cannot deduplicate the two.

For full control, disable the browser (fbq) event in the form settings. Then, configure a tag in Google Tag Manager to listen for the branchside_form_submission dataLayer event upon successful form submission.

To start using Meta CAPI:

Navigate to your form settings and select the Conversions tracking section. Select an existing Facebook conversion or click the "+ Add new conversion" button.

In the pop-up window select "Facebook" under the Platform dropdown and the event name you want to send to Meta.

Click "Add" button.

The event list contains Meta's standard event names. Purchase is only available for offline conversions, not for form conversions.

Click on the "Details" button next to your conversion event.

Click the "Set up server-side tracking" button in the Server-side conversion tracking section.

In the pop-up window click on the "Add Pixel" button.

Enter the details for your pixel:

• Pixel Name - a name for your pixel; this will only be visible within your dashboard.

• Pixel ID - copy and paste your pixel ID from the Facebook Events Manager dashboard.

• Pixel Access Token - in the Facebook Events Manager, go to the pixel settings and find the "Generate access token" button. Generate a new token and copy the value.

Click on the "Add" button.

You'll be able to use this configured pixel in other conversions and forms across your organization.

Please note that all organization members will be able to view your pixel settings.

After your pixel is created, click the "Select" to attach it to your front-end conversion event.

Save your form.

Editing or deleting a Pixel affects every form that uses it. Editing updates the credentials for every form connected to that Pixel, and deleting a Pixel from the selection window also deletes the server-side configuration of every form that uses it.

If you don't use Google Tag Manager, you can have Branchside fire the Pixel event in the visitor's browser after every form submission — an alternative to building the tag yourself as described in Track form submissions with the dataLayer.

1. Open the "Details" window of your Facebook conversion in the Conversions tracking section.

2. Turn on the "Browser event" toggle.

By default the toggle starts off for every Facebook conversion added on the form creation page.

What happens on submission:

• Branchside calls fbq("track", "<Event>", {}, {eventID: "<id>"}), using the same event name as the server-side conversion.

• The eventID is included only when a server-side event was queued for that submission.

• If the Meta Pixel base code is not loaded on the page, nothing fires. Branchside does not install or load the Pixel base code for you; loading the Pixel and handling its consent is the site owner's responsibility.

• The browser event is available on every plan and turning it off never stops server-side tracking — the server-side dispatch runs first.

Example: your site loads the Pixel when analytics consent is granted, but the visitor denied ad_storage. The browser event then fires as a browser-only conversion with no Event ID and no server-side event. When the Pixel loads under ad_storage consent and a server event is queued, both sides share the Event ID and Meta deduplicates them.

To enhance your Meta CAPI event match quality, you can map your form fields to send Personally Identifiable Information (PII) to Meta.

1. On the form edit page, navigate to the "Conversion tracking" section.

2. Click on "Field mapping".

3. Expand the "Facebook" section. In this section, we have listed 8 default Facebook fields that can be mapped with any of your form fields:

   • Email (em)
   • Phone (ph)
   • First Name (fn)
   • Last Name (ln)
   • City (ct)
   • State (st)
   • Zip (zp)
   • Country (country)

4. Select the appropriate form field for each Facebook PII field (e.g., Email, Phone Number, First Name).

Your field mappings are shared: the same mapping is used for server-side conversions and for offline conversions.

Remember that sending PII requires the user to grant ad_user_data consent.

Pro tip:
You can use a hidden field with a predefined value to map it to Facebook parameters.

For example, if you run a local business, you can add a hidden field with a two-letter country code and map it to the Country (country) parameter. This way, our system will hash the value and send it to the pixel with every server conversion.

You can verify that Meta is receiving your server-side events properly using the Test Events tool:

1. Go to your Meta Events Manager and open the "Test events" tab for your dataset.

2. From the "Select channel" dropdown, choose "Website".

3. Expand the "Confirm your server’s events are set up correctly" section.

4. Copy the Test Event Code (it looks like TESTxxxxx).

5. In your form's Conversions tracking section, click "Details" next to your Facebook conversion, and paste this code into the "Test event code" field under Server-side conversion tracking.

6. Submit a test entry on your form. Make sure you have granted consent on your website (at least ad_storage), otherwise the event will not fire.

7. Check the delivery in Branchside first: open the form's Submissions list, click the "Server Events" button on the entry and watch the status go from pending to success.

8. The event should then appear in your Meta Events Manager within a few moments.

The Test event code applies to submission events only — offline conversions are never sent with a test code.

Remember to remove the Test Event Code from your form settings once testing is complete — use the "Clear" button next to the field — or Meta will continue to treat real conversions as test events.

Every dispatched event — server-side and offline — is recorded with the submission it belongs to.

1. Open the form's Submissions list.

2. Click the "Server Events" button on a submission row. The button is hidden for submissions that have no events.

3. In the modal, filter with All / Server-side / Offline conversions and check the columns:

   • Event name
   • Platform
   • Type
   • Created at
   • Status — pending, success, or failed

Sometimes the conversion you care about happens long after the form was submitted — an in-store sale, an order taken over the phone. Offline conversions let you record those outcomes and send them to Meta's Conversions API.

Offline conversions require an active Growth or Business plan. Check our pricing page for more details.

Learn more on How to Send Offline Conversions

• The event name you selected, with physical_store as the action source.

• The event time is the moment you send, not the submission time.

• Every conversion counts. Each record gets a new Event ID for every send, and nothing is deduplicated: a lead with several purchases produces one event per purchase, and sending the same submission again counts again.

• User data: the IP address and user agent stored with the submission, fbp/fbc from the submission's stored advertising cookies, and your hashed mapped fields — but only when ad_user_data consent was granted at submission time.

• Custom data: the conversion value and currency, but only when both are present.

Offline conversions also work with Google Ads — see Offline Conversions for the general flow.

Check the following, in order:

• Consent. ad_storage must have been granted when the submission was made. Without it, no server-side event is dispatched — this is expected behaviour, not a failure.

• Plan. Server-side tracking requires the Growth or Business plan.

• Enabled toggle. The conversion's server-side tracking must be enabled.

• Pixel details. Check the Pixel ID and access token in the Pixel settings.

• Check the "Browser event" toggle is on in the conversion's Details window. It starts off for conversions added on a new form.

• Check that the Meta Pixel base code is loaded on your page. Branchside never loads the Pixel for you — if fbq does not exist, nothing fires.

Both sides must use the same Pixel and the same event name. The browser event only carries an eventID when a server-side event was queued for that submission — and if your page loads a different Pixel than the one selected for server-side tracking, Meta treats the events as unrelated.

• Check the 90-day window: older submissions are not eligible.

• The ad_storage consent must be granted at submission time.