Meta Ads (Conversions API)
The server event carries what the browser never saw.
Pixel-only tracking loses the customer who converts on another device or after the cookie died. This connection sends the confirmed outcome through the Meta Conversions API while the Pixel stays in the loop for deduplication.
Pages marked Planned are complete specifications written before the connector ships. They validate demand. Connectors with real delivery logs are marked Production or Beta.
The Pixel sees less every year
Browser limits, consent prompts, and cross-device journeys break cookie-based attribution. Meta optimizes on partial signals while your CRM holds the complete story.
One event_id, two channels, zero double counting
Apointo sends lead and purchase events with fbp and fbc identifiers plus a stable event_id. Meta matches server events against Pixel events and counts each customer once. The CRM outcome becomes a signal bidding can use.
- 01Ad click (fbclid, _fbp / _fbc cookies)
- 02Apointo Capture stores the click
- 03Your CRM or checkout confirms the outcome
- 04Apointo sends the server event
- 05event_id deduplicates against the Pixel
Capture stores fbclid and the _fbp and _fbc cookies on first touch.
Your CRM confirms qualified leads and sales.
Apointo posts server events with hashed identity fields and stable event ids.
Logs show every accepted, rejected, and retried delivery.
| From | Apointo |
|---|---|
| Form or lead captured | Lead server event |
| Qualified lead stage | QualifiedLead custom event |
| Purchase confirmed | Purchase server event (value + currency) |
Will events double count against the Pixel?
No. Every server event carries the same event_id as its Pixel counterpart. Meta deduplicates and counts once.
How is personal data handled?
Identifiers are normalized and hashed before they leave Apointo, and only events with consent evidence are eligible for delivery.
When does this connector ship?
This page is the working specification. Join the early-access list and build order follows demand.