Lead Ads CRM CAPI: Closing the Lead Loop in Meta

The Lead Ads CRM CAPI loop exists because the form submission and the real lead are different facts. Lead Ads delivers instant, native-form leads into your CRM - and most of them are exactly what they look like: unverified intent. The lead that deserves to travel back to Meta as a conversion signal is the one your CRM confirmed. This guide wires that loop: form data into the CRM, confirmation and enrichment, the documented CAPI lead event with hashed contact fields, and the dedup and window rules that bound how late a confirmed lead can still count.

The sibling topic - offline conversions uploaded in bulk rather than delivered per lead - is covered in Meta CAPI offline conversions and lead CRM; this page is the per-lead wiring.

Two Signals: The Form Lead and the Confirmed Lead

Lead Ads forms convert frictionlessly - which is their feature and their problem. The moment a form is submitted, two facts exist: someone expressed interest (now), and - later - someone qualified. Treating both as the same event wastes the difference:

Buyers optimizing pure form volume teach the algorithm to find more form-fillers; buyers sending only confirmed leads get quality but starve volume. The two-event split - instant form event, confirmed-lead event after qualification - keeps both signals without merging them, the same two-stream logic as the COD approve rate guide.

Into the CRM: What the Form Delivers

Lead Ads forms deliver natively: submitted fields land in the ad platform and, via the native integration or a connector, in your CRM within minutes. What the CRM contributes is the part the form cannot: qualification status from your follow-up process, the communication timeline, and - crucially for the return trip - the verified contact data (email, phone) that makes a strong match key.

Data handling at this stage sets up the return delivery: contact fields will travel back to Meta as SHA-256 hashed values with documented normalization (lowercase email, digits-only phone with country code), per the customer-information rules (customer information parameters). Capture them cleanly once, and the return hop is mechanical.

The Return Hop: Confirmed Lead as a CAPI Event

Documented event requirements apply in full. For website-action events, action_source, event_source_url, and client_user_agent are required; contact data travels hashed; and a stable event_id should be generated per lead (Conversions API parameters). The wiring:

1. A CRM confirmation - status change, deal stage, or webhook - triggers the delivery layer.
2. The layer builds the event: lead or purchase-class name, hashed em/ph from the CRM record, and event_time at confirmation.
3. A stable event_id is derived from the lead's identity - not because Meta merges duplicates (its dedup pairs a browser pixel with a server event and never merges two server events), but because it lets the delivery layer be idempotent: a lead already sent is skipped on re-sync.

That last field - the conversion identity - matters more in lead loops than anywhere else: CRMs re-sync and statuses change, and since Meta never merges two server events, only a delivery layer that remembers which leads it already sent keeps the count honest (the dedup rules cover the cross-channel case).

The Bound Rules: Dedup and the Seven-Day Window

Two documented rules bound the loop:

1. Deduplication. Meta pairs browser and server events and keeps the first copy within its dedup window; two server events with the same event ID are not merged - the dedup rules are cross-channel only. In a lead loop this means: pick one delivery path per lead, or count on doubles.
2. The window. event_time may sit at most seven days in the past, and one stale event fails an entire request (using the API). A lead confirmed eight days after the form cannot be delivered as a fresh event - another argument for fast confirmation flows.

Bulk uploads of older lead batches are the offline-conversions territory covered in the offline guide, not the per-lead CAPI path.

Verifying the Loop

1. Submit a real test lead through the Lead Ads form.
2. Watch it land in the CRM with clean contact fields.
3. Confirm it in the CRM and verify the CAPI event fires - Meta's Test Events shows arrivals, and Events Manager reflects them within about 20 minutes (get started).
4. Check the hashed fields against the normalization rules, then force a CRM re-sync of the same lead and verify only one event arrived - if two did, the delivery layer is not deduplicating.

Pixel Activator can pre-verify the Meta leg for free, and the postback troubleshooting checklist covers the CRM-to-delivery failure modes.

Lead Ads CRM CAPI: Frequently Asked Questions

Sources