LinkedIn lead gen forms: webhook routing

Why route LinkedIn leads in real time?

A buyer who fills in a Lead Gen Form expects a reply while the question is still on their mind. When leads wait in Campaign Manager until someone downloads a CSV, the reply can come a day later, after the buyer has moved on. Routing each lead as it arrives closes that gap.

LinkedIn's own guidance points the same way. Its Lead Sync documentation recommends the push model, webhooks that fire when a lead is created, over polling the API on a schedule, because polling adds delay. It suggests combining both: push for speed, a periodic pull to catch anything missed.^[1]

Native sync or a webhook?

Start with the simplest route that meets the need. LinkedIn integrates Lead Gen Forms with CRM and marketing automation partners such as Salesforce Sales Cloud and HubSpot, and leads flow without code.^[4] If your platform is not supported, leads can still be downloaded as a CSV, which is fine for low volume and too slow for anything else.

A native sync is a one-to-one pipe. Build your own routing when you need rules the pipe cannot apply:

• Several destinations. Small companies go to one sales queue, large accounts to another, partners to a third system.

• Form-specific handling. A contact-sales form and a guide download should not land in the same queue.

• Consent rules. Leads who did not agree to marketing email must not enter a nurture flow.

Note that LinkedIn warns some CRM partners do not support hidden fields, profile links or custom checkboxes.^[4] If your routing depends on hidden fields, test the native sync with a test lead before you rely on it.

How do LinkedIn lead webhooks work?

A lead notification is a small event, not the lead itself. LinkedIn documents its fields as the lead's URN, the form, the owner, the associated entity, the lead type, the action (created or deleted) and a timestamp.^[2] Your service then fetches the full response, with answers, hidden fields and consent choices, from the leadFormResponses endpoint.

Setup has a few rules worth knowing before you start:^[1][2][3]

1. Access. Lead Sync is a separate API product. Your app needs approval and the lead permissions, and the user who connects it needs an ad account role such as account manager, campaign manager or leads manager.

2. Subscriptions. For lead syncing, webhook subscriptions are created through the Lead Notification Subscriptions API, not the developer portal screens. An app can hold up to 1,500 of them; LinkedIn recommends one per owner unless you need form-level ones.

3. Validation. Only HTTPS endpoints that pass validation receive new lead notifications.

How do you validate the endpoint?

LinkedIn proves you own the endpoint with a challenge. It sends a GET request with a challengeCode. Your endpoint replies within 3 seconds with a 200 status and a JSON body that holds the code and a challengeResponse: the lowercase hex HMAC-SHA256 of the code, keyed with your app's client secret.^[3]

Validation is not one-off. LinkedIn re-validates endpoints every 2 hours, and after 3 failed checks in a row the endpoint is blocked and stops receiving events.^[3] Two common causes are a cold start that takes longer than 3 seconds and a redirect in front of the endpoint.

For each notification, your service must also:^[3]

• Check the signature. Compute the HMAC-SHA256 of the string "hmacsha256=" plus the raw request body, keyed with the client secret, and compare it with the X-LI-Signature header. Discard any event that does not match.

• Deduplicate. LinkedIn can deliver a notification more than once, so store each notification's key and skip repeats before you create a CRM record.

• Return a 2xx status. Any other status counts as a failed delivery.

How should routing rules work?

Once the lead is fetched, routing is a short decision list. We keep it in this order:

1. Consent first. Read the consent responses before the lead touches any marketing tool. A lead without marketing consent can still go to sales, but not into a nurture flow.

2. Existing owner. Match the email domain against accounts in the CRM. If the account has an owner, route to them rather than the general queue.

3. Form and campaign. Use the form and campaign IDs, and any hidden fields you set on the form, to pick the queue and the follow-up.

4. Region and size. Send leads to the team that covers the buyer's market.

Then act in parallel: create or update the CRM record, alert the owner in the tool they watch, and send a short reply from that owner. Keep the campaign and form IDs on the record, because closed-loop reporting needs them to tie spend to pipeline later.

Can GA4 report these leads?

Leads from LinkedIn's forms never reach your website, so no analytics tag fires. Google's Measurement Protocol can send server-side events to Google Analytics, including offline ones, but Google describes it as a supplement to tagging, joined to website activity through a client ID.^[5] A LinkedIn form lead has no such ID, so the event cannot join a website session.

For most B2B teams the CRM is the better system of record for these leads. Report LinkedIn form leads, meetings and opportunities from the CRM, next to the other channels, and use analytics for on-site behavior.

Where do teams go wrong?

• Treating the notification as the lead. It holds an ID; the answers need a second call.^[2]

• Hard-coding one destination. Rules change as sales coverage changes, so keep them in one config, not spread across scripts.

• Skipping the pull. A scheduled pull of recent leads catches anything a failed delivery missed.^[1]

• No test leads. Send test leads after every form change, because editing a form can break field mapping in connected tools.^[2]

If you also run Thought Leader Ads to warm up accounts, route the leads from the follow-up campaigns the same way, and use behavior-based email for the leads sales is not ready to call. Our B2B PPC service and the digital marketing pillar cover how paid social connects to the rest of your pipeline.