Throttle + Meta Pixel and Conversions API

What the integration does

Throttle reports purchases to Meta from both sides at once, the way Meta recommends:

• Pixel. On hosted checkout, Throttle loads your Meta Pixel and fires PageView and Purchase. On embedded checkout, your own pixel fires Purchase from the completion event.
• Conversions API. Throttle’s server sends the same Purchase with value, currency, and content_ids taken from each line item’s reference id.

Both carry the order id as the event id, so Meta deduplicates them and you can leave both on. Server-side events survive ad blockers and browser tracking limits that drop pixel fires.

Match quality

The Conversions API event includes a SHA-256-hashed email, the buyer’s IP address and user agent as seen by Throttle’s server, and the fbp and fbc click identifiers captured in the order’s clientContext — the fields Meta uses to match a purchase to the ad that drove it.

Setting it up

In your application’s Tracking settings, enter your Pixel ID and, for server-side events, a Conversions API access token — stored server-side and masked after saving. Settings are per application and per environment.

Consent is respected per channel: Meta events need marketing consent, separately from the analytics consent GA4 uses.

Good to know

• Purchase is the conversion event Throttle sends; subscription renewals aren’t forwarded.
• There’s no test_event_code support, so point non-production environments at a test pixel.
• Catalog sync isn’t built in — Throttle doesn’t store products. The product feeds guide shows how to keep your feed’s ids matching Throttle’s.
• Conversions API sends are best-effort and aren’t retried.