FlowKit

Automatically pulling Facebook and Instagram Ads leads into your CRM with n8n

Published 1 August 2026 · 5 min read

A Facebook or Instagram Ads campaign with an instant form generates leads directly inside Meta's ecosystem — nowhere else. Without an integration, those leads sit in Ads Manager until someone runs a manual CSV export, usually once or a few times a day. By the time someone opens the export, filters out test submissions, and copies contacts into the CRM, several hours have passed since the submission — exactly the window where an ad lead is most receptive. A well-known study on online lead management, Oldroyd, McElheran, and Elkington (2011), The Short Life of Online Sales Leads, published in Harvard Business Review, measured an average first-response time of 42 hours among the companies studied, while the odds of qualifying a lead drop sharply after the first hour. An n8n pipeline wired directly to the Meta form removes that latency: the lead lands in the CRM within seconds, with no export and no copy-paste.

The native node: Facebook Lead Ads Trigger

n8n ships a dedicated trigger, Facebook Lead Ads Trigger (n8n-nodes-base.facebookLeadAdsTrigger), which subscribes to Meta's webhook notifications for one or several Pages and forms. In practice, every time someone submits an instant form tied to your Page, Meta pushes a notification to the webhook URL n8n generates — no polling, no periodic API calls.

Pay close attention to what that notification actually contains, though: it does not carry the form answers, only identifiers — leadgen_id, page_id, form_id, ad_id, created_time. That's a Meta-side security measure, not an n8n limitation. To retrieve the name, email, phone number, and custom questions, you need a second call, through a Facebook Graph API node or a plain HTTP Request against https://graph.facebook.com/v25.0/{leadgen_id}, authenticated with the same token as the trigger.

Setting up the Meta app and credential

Before any real lead arrives, three prerequisites on the Meta side condition everything else:

  1. A Meta for Developers app created at developers.facebook.com, with an existing ad Page and instant form.
  2. The leads_retrieval permission requested in Advanced Access through Meta's App Review — Standard Access only works for testing with your own Pages and forms as an app admin or tester. As soon as the campaign targets real ad prospects, Advanced Access (and typically a verified business in Business Manager) becomes mandatory.
  3. The app switched to Live mode, with a privacy policy URL filled in under basic settings — Meta refuses to run a production webhook on an app still in development.

On the n8n side, the Facebook Lead Ads credential is then set up with the App ID, App Secret, and an access token carrying the permission above — a process similar to the one described in our Google OAuth2 setup guide, transposed to the Meta ecosystem.

The gotcha to know: one webhook per app

Meta only allows a single registered webhook URL per app, while n8n generates two distinct ones for each trigger: a test URL (active while the workflow is open for editing and unpublished) and a production URL (active once the workflow is published). Switching from one to the other overwrites the previous registration on Meta's side — the two URLs can never receive notifications at the same time.

In practice, this calls for a simple discipline: unpublish the workflow to test with the test URL, republish before switching back to production, and never leave both versions active at once assuming one "takes over" automatically. Running a test while a real campaign is live in production will drop incoming leads for the duration of the test — reserve testing for off-peak hours or a dedicated test Page.

Building the pipeline after receiving the lead

Once the leadgen_id has been received and the form data retrieved through the Graph API, the pipeline looks like any other inbound lead capture:

  1. Deduplication — Meta can notify the same lead twice on a network retry on its end; compare the leadgen_id against a table of already-processed leads before going further, on the same principle as our guide on n8n webhook idempotency.
  2. Field normalization — an ad lead arrives as generic question/answer pairs (full_name, email, a custom question like "Approximate budget"…) that a Set node turns into clean fields consistent with the rest of your pipeline.
  3. Optional enrichment — if the lead only supplies a work email with no company context, the same mechanics as our article on automatic lead enrichment (domain lookup, business registry, site visit) apply as-is.
  4. AI qualification — a priority score based on the form answers (stated budget, urgency, industry) follows the same logic as our AI-based inbound lead qualification guide, with an immediate Slack alert for hot leads.
  5. CRM write — creating or updating the contact follows the same best practices (search by email before creating, custom field mapping) as our HubSpot or Pipedrive CRM sync guide.

Making the pipeline reliable

An ad lead can arrive during a spike — a campaign launch, a weekend budget increase — with nobody watching the n8n instance at that moment. A dedicated Error Workflow that catches every failure (an expired Graph API token, an unreachable CRM) and alerts instead of letting the execution die silently keeps an expensive ad lead from vanishing without a trace. For traceability, logging every processed leadgen_id into a Supabase table — see our n8n-to-Supabase connection guide — doubles as a safeguard against duplicates and an audit trail if a lead billed by Meta was never actually received.

Common pitfalls

  • A Graph API token with the wrong lifetime. A regular user token expires within hours; use a long-lived Page token so the workflow keeps running without repeated manual intervention.
  • The form changes after the workflow is set up. Adding or renaming a custom question in Meta Ads Manager changes the field key returned by the Graph API — retest the mapping after every change to the ad form, not just at initial setup.
  • Forgetting that a development app only sees test leads. The most common setup mistake: the workflow seems to work in testing, then receives nothing once the campaign actually goes live, for lack of Advanced Access approved through App Review.

Going further

The architecture described here — inbound webhook, deduplication, enrichment, AI scoring, CRM write — is exactly what powers the AI Inbox Pack (€79) for sorting inbound emails. Adapting the Facebook Lead Ads trigger to the same mechanics only changes the signal's source, not the business logic that follows. And for a team handling both ad leads and an inbox to sort, the Complete FlowKit Bundle (€269 instead of €347) covers both with the same approach.

FAQ

Frequently asked questions

Does the Facebook Lead Ads Trigger node also work for Instagram forms?

Yes: lead generation campaigns on Instagram use the same instant-form infrastructure as Facebook (managed from the same connected Page in Meta Ads Manager), so the same node and the same webhook capture submissions from both Facebook and Instagram indifferently.

Why does the node only return a few IDs instead of the actual form answers?

That's how the Meta API works: the webhook notifies you that a lead exists (leadgen_id, page_id, form_id, created_time) without sending its content, for security and load reasons. A second call, through a Facebook Graph API or HTTP Request node against the /{leadgen_id} endpoint, is needed to retrieve the actual form answers (name, email, phone, custom questions).

Do you need Meta app approval before receiving real ad leads?

Yes. An app in development mode only receives test leads submitted by the app's admins or testers. To capture leads from real campaigns, the app must go Live, obtain the leads_retrieval permission in Advanced Access through Meta's App Review, and typically rely on a verified business in Business Manager.

Can several forms or several Pages feed the same workflow?

Yes, the node supports selecting several forms tied to the same Page. For several Pages with different routing (a distinct CRM or pipeline per campaign), a common pattern is a Switch node right after the Graph API call, routing on the page_id or form_id field returned by the trigger.

Bundle FlowKit Complet

€269