- Why there is no plug and play connector
- The two routes that work
- Step by step: building the custom integration
- The MySQL table structure that holds up
- Why the webhook alone isn't enough
- What this costs to build
- What moves the needle after the data lands
- When to build it yourself versus bring someone in
- Frequently asked questions
- Useful references
The short version: there is no native button that pipes Facebook Lead Ads into MySQL, so you either pay a tool like Zapier or Make to bridge the two, or you build a webhook that catches the leadgen event, calls the Graph API for the full lead data, and writes it straight into a table. I have built both versions for clients, and I will show you the actual table structure, the exact steps, and the bit nobody tells you about webhooks quietly failing.
Why there is no plug and play connector
Facebook (Meta) built Lead Ads to keep people inside the platform for as long as possible. The forms live natively in the Facebook and Instagram apps so nobody has to leave to fill in a form, which is great for conversion rates and a bit of a headache for anyone who wants that data somewhere else fast. Meta gives you a Graph API and a webhooks system, not a database connector. That gap is where every "integrate Facebook Lead Ads" guide either sends you to a paid tool or leaves you stuck on page one.
I run into this constantly with clients who assume, reasonably, that because Facebook lets you export leads as a CSV from Ads Manager, there must be an equally simple live feed. There isn't. The CSV export is manual and it lags. If you want leads landing in a database the moment someone submits a form, you need either a middleware tool subscribed to the webhook, or your own script doing the same job.
The two routes that work
Route one: a middleware tool (fastest to set up)
Zapier, Make.com and n8n all offer a Facebook Lead Ads trigger that fires when someone submits a form. From there you add a MySQL action step (Zapier and Make both have direct MySQL connectors, as long as your database is reachable from the internet, which usually means whitelisting the tool's IP range on your host).
- Zapier: Facebook Lead Ads trigger plus MySQL "Create Row" action. Costs from about £19 a month for the tier that supports multi-step Zaps with a database action, more if you're running high volumes.
- Make.com: same idea, cheaper entry point, plans from around £8 a month, and the visual flow is easier to debug when a lead goes missing.
- n8n: self-hosted and free if you run it on your own server (a £5 a month VPS is plenty), paid cloud plans from around £16 a month if you don't want to host it yourself.
This route takes an afternoon. It's the right call for a small business running one or two campaigns and fewer than a few hundred leads a month. It's the wrong call once you're past that, because you start hitting per-task limits and the monthly bill for a "simple" data pipe becomes a odd thing to be paying for.
Route two: a custom webhook into MySQL (the one I build for clients)
This is more setup work up front but it's free to run and you own it completely. It's also the version that survives when a client's lead volume goes from 20 a month to 400 a month, which happens more often than people expect once a campaign starts working.
Step by step: building the custom integration
- Create a Facebook App. Go to developers.facebook.com, create a new app under the "Business" type, and note your App ID and App Secret.
- Add the Webhooks product to the app and subscribe to the "leadgen" field under the Page object. Facebook will ask you to verify a callback URL with a token you set yourself, so you need your endpoint live before you can finish this step.
- Verify domain ownership for the site hosting your webhook endpoint, through Business Manager. Skip this and Facebook will silently refuse to send anything.
- Request the leads_retrieval and pages_manage_ads permissions and submit for App Review if you're not just using this on your own page under your own admin account. Review typically takes three to seven business days, and I've had it bounced on the first submission twice for vague use-case descriptions, so write the use case out plainly: "Retrieve lead data from Facebook Lead Ads forms and store it in our CRM/database for follow-up."
- Build the webhook receiver. A simple PHP endpoint works fine:
<?php
if ($_SERVER['REQUEST_METHOD'] === 'GET') {
if ($_GET['hub_verify_token'] === 'your_secret_token') {
echo $_GET['hub_challenge'];
exit;
}
}
$data = json_decode(file_get_contents('php://input'), true);
$leadgen_id = $data['entry'][0]['changes'][0]['value']['leadgen_id'];
$access_token = 'your_page_access_token';
$url = "https://graph.facebook.com/v19.0/{$leadgen_id}?access_token={$access_token}";
$lead = json_decode(file_get_contents($url), true);
// insert $lead into MySQL here
?>
Facebook's webhook only sends you the leadgen_id, not the actual answers. You then call the Graph API with that ID to pull the field data (name, email, phone, whatever custom questions were on the form). This two-step handshake trips up almost everyone the first time, because the sample payloads in Facebook's own documentation make it look like the full lead arrives in one hit. It doesn't.
The MySQL table structure that holds up
Here's the table I use as a starting point for most clients, adjusted for their form fields:
CREATE TABLE fb_leads ( id INT AUTO_INCREMENT PRIMARY KEY, lead_id VARCHAR(50) NOT NULL UNIQUE, form_id VARCHAR(50), campaign_id VARCHAR(50), full_name VARCHAR(150), email VARCHAR(150), phone VARCHAR(30), raw_payload TEXT, created_time DATETIME, processed TINYINT DEFAULT 0, inserted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
Two columns are doing more work than people expect. raw_payload stores the full JSON response from Facebook, even the fields you don't have named columns for, because custom questions get added to forms constantly and you don't want to lose data because your schema didn't have a column for "preferred callback time" that someone added to the form last Tuesday. And processed is there so your sales team's CRM sync or notification script can flag a row as handled without deleting it, which matters when someone inevitably asks "did we get a lead from that campaign on the 14th" three weeks later.
Why the webhook alone isn't enough
Facebook's own documentation includes a quiet admission that webhook delivery isn't guaranteed. Under load, or during platform issues, a small percentage of leadgen events simply don't fire the webhook. In my experience running this for a boiler and heating client in the Midlands, sending around 35 to 50 leads a day at peak, we found roughly 2 to 3 percent of leads never triggered a webhook at all. They existed in Ads Manager but never showed up in our database.
The fix is a cron job that polls the Graph API directly every 15 minutes, requesting leads created since the last poll, and inserting any that aren't already in the table (this is exactly why lead_id needs to be unique). It's not glamorous, it's a five-line scheduled script, but it's the difference between "we think we're getting all our leads" and knowing you are.
What this costs to build
For a custom build like the one above: 8 to 15 hours of developer time, depending on how many form variants and campaigns you're pulling from. At UK freelance rates of £50 to £120 an hour, that's roughly £400 to £1,800 as a one-off cost, versus an ongoing £20 to £70 a month for a middleware tool that starts to strain once you're past a few hundred leads a month. For most small businesses under that volume, paying monthly for Zapier or Make is the cheaper and less stressful option, and I tell clients this even when it means less billable work for the developer side of things.
What moves the needle after the data lands
Here's the part most guides on this topic skip entirely. Getting Facebook Lead Ads into MySQL is a plumbing problem, and plumbing problems are satisfying to solve because they're finite and you know when you're done. But I've watched more than one client build a solid integration, get leads landing in the database within seconds of submission, and then still lose the deal because nobody looked at the table for six hours.
The Facebook lead form format makes this worse, not better. Because the form is pre-filled with the person's Facebook profile name, email and phone number, a huge share of these leads are low-intent taps, someone scrolling and hitting submit out of curiosity rather than genuine buying interest. Response speed is the entire game with this lead type, and research from InsideSales (now Xant) years ago found contact attempts made within 5 minutes convert around 21 times more often than attempts made after 30 minutes. That gap has only gotten worse as people's attention spans have shortened, not better.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
So the database is step one, not the finish line. The moment a row is inserted, something needs to fire an SMS or a call task to a real person, not sit in a table waiting for someone to open a report. If you're building this integration to feed a CRM or a follow-up system rather than just archive data, that's the far more valuable half of the project, and it's the half people skip because it's harder than a webhook.
When to build it yourself versus bring someone in
If you're comfortable with PHP or Node and you've got one page, one or two forms, and a few hundred leads a month, the custom route above is a weekend project. If you're running Lead Ads across multiple pages, multiple business units, or you need this wired into a CRM with proper deduplication and lead scoring rather than a flat table, it's worth getting someone who's built this exact pipe before rather than debugging App Review rejections and silent webhook failures on your own time. That's a fair chunk of what I do when clients bring me in for AI and marketing systems work, joining up the ad platform, the database, and the follow-up automation so leads don't just get stored, they get worked.
Related reading: facebook keeps charging me for ads.
For the rest of the series, see the Facebook Help: 80 Guides to Pages, Groups, Ads, Stories and Fixes.
Frequently asked questions
Can I connect Facebook Lead Ads to MySQL without any coding?
Yes, using Zapier or Make.com, both of which offer a Facebook Lead Ads trigger and a direct MySQL action step, no code required, though you'll need to whitelist the tool's IP address on your database host and the monthly cost scales with volume.
Why does my webhook receive a leadgen_id but no actual lead data?
Facebook's webhook only sends the ID of the new lead as a security measure. You then have to make a separate call to the Graph API using that leadgen_id and your page access token to retrieve the actual form answers.
Do Facebook Lead Ads webhooks ever fail to fire?
Yes. In client accounts I've managed, roughly 2 to 3 percent of leads never triggered a webhook event despite existing in Ads Manager, which is why a scheduled polling script as a backup matters more than most setup guides suggest.
How fast do I need to follow up with a Facebook Lead Ads lead?
As fast as possible. Contact attempts made within 5 minutes of submission convert dramatically better than later attempts, and because Lead Ads forms are pre-filled, many submissions come from low-intent taps that go cold within the hour if nobody responds.
Useful references
Want this done for you? See hosting write for us page.
