How to send qualified LinkedIn leads to your CRM or your own app by webhook

TL;DR: To push qualified LinkedIn leads into your CRM or your own outreach system, connect traxy's Webhook integration to an HTTPS endpoint you control, send a test payload, then add a route from a saved lead view to that endpoint with Auto or Manual delivery. traxy sends signed lead events, one when a qualified lead first reaches the destination and another when a known lead engages again, and your receiver verifies the signature, de-duplicates and writes the record. If you'd rather pull than push, the REST API reads leads, signals and engagements with an API key. From Claude or ChatGPT, the traxy MCP can create the destination and queue a lead for delivery.

Last checked: November 12, 2026, against traxy's Webhook, routes, API and MCP overview and MCP tools docs.

How do I push LinkedIn leads into my CRM or my own outreach system?

Point a traxy webhook at your system's HTTPS endpoint and route a saved lead view to it, so every qualified lead that enters the view arrives as a signed event. Use the REST API instead when your system should pull leads on its own schedule.

This is the setup for teams with a custom CRM, an in-house sales tool, a data warehouse or a self-built outreach system, where a native connector doesn't exist or wouldn't fit. The traxy side is the same for all of them:

1. Prepare a receiver. An HTTPS URL that accepts POST requests outside a temporary test session.

2. Connect it. Integrations > Webhook: a connection name, the endpoint and an authentication header if your receiver needs one.

3. Test it. Send test payload fires one immediate request so you can map fields before real leads arrive.

4. Route an audience. A route connects one saved view (or All leads) to the endpoint, with Auto or Manual delivery.

5. Handle events safely. Verify X-Traxy-Signature and X-Traxy-Timestamp, de-duplicate, and treat first-delivery and repeat-engagement events differently.

Each step is covered below, with what traxy does, what you build, and the limits the docs spell out (Webhook, routes).

What leads does traxy send, and why push them at all?

traxy sends high intent leads it found from LinkedIn social intent: people who like, comment on or write posts about the problem you solve, people who engage with posts from the profiles, posts and company pages you track (competitors, creators, your own team), and people found through social intent search across 71M+ scanned LinkedIn likes, posts and comments. A person only counts as a lead with a 50%+ match to your ICP, and every lead carries the post, comment, like or repost that put them on your list.

That evidence is the reason to push leads somewhere rather than export a static list. A record in your CRM that says "commented on a post about switching CRMs, with a strong ICP match" gives the rep something real to open with. A record with only a name and title looks like any purchased list.

It also explains the two event types. A first-delivery event means a person entered the routed audience as a qualified lead. A repeat-engagement event means someone you already have engaged again, which usually belongs on the existing record as a new activity, not as a new contact (Webhook).

Pushing leads out is optional. traxy runs your entire LinkedIn GTM end to end, from finding high intent leads from social intent to enriching and researching each one, to running relevant, personalized LinkedIn and email outreach to them on autopilot. Autopilot here means a campaign runs on its own after you approve it, or you approve every message. Many teams do both: the webhook keeps the CRM current while a traxy campaign handles the outreach (more on that further down).

Webhook, REST API, Zapier or n8n: which fits?

Use the webhook when you own the receiving code and want each lead pushed to it. Use the REST API when your code should pull on its own schedule. Use Zapier or n8n when you'd rather build the flow without hosting a service. Use the MCP when you want to set it up or send a lead from your AI chat.

The REST API and the MCP authenticate differently. REST uses an API key tied to one workspace. The MCP uses an OAuth access token and works with the authorized default workspace or an explicit workspaceId (API and MCP). The REST API is for application reads; it does not send leads anywhere or send messages. For the pull side in detail, see the LinkedIn leads API guide. For Salesforce in particular, see how to send qualified LinkedIn leads into Salesforce.

When should I pull with REST instead of pushing?

Pull when your system already runs scheduled jobs, when you want to backfill a lot of history in one pass, or when you want the full signal and engagement history for each lead rather than one event at a time. The base URL is https://api.traxy.ai/api/v1, and the endpoints include GET /customer/leads, GET /customer/leads/signals and GET /customer/leads/{leadId}/engagements. A common pattern is both: the webhook for new leads, and a nightly REST read that fills in signals and engagements.

curl --fail-with-body \
  'https://api.traxy.ai/api/v1/customer/leads?limit=1' \
  --header 'Authorization: Bearer YOUR_TRAXY_API_KEY'

Setting up a webhook destination and testing it

Create the receiver first, connect it under Integrations > Webhook, then send a test payload and confirm it arrived before you add any route. A connection on its own sends no leads; the route does.

Step 1: Prepare the receiver

• Expose an HTTPS endpoint that accepts POST requests. A serverless function, a route in your existing backend or a small service in front of your CRM all work.

• Make sure it accepts requests outside a temporary test session. Some workflow tools give you a test URL that only listens while you watch it; use the production one (Webhook).

• Decide whether the endpoint needs an authentication header. Prepare one only if your receiver requires it.

• Log the request body and headers during setup so you can compare them with the samples in Payload & help.

Step 2: Connect it in traxy

1. Open Integrations > Webhook.

2. Enter a connection name and the HTTPS endpoint.

3. Add the authentication header if your receiver needs one, and save the connection.

4. Open Settings to review the triggers and Payload & help.

An authentication header you saved earlier stays saved when its edit field is left empty. To clear it, use the explicit removal action rather than blanking the field (Webhook).

Step 3: Send a test payload

Select Send test payload and check that the request reached your receiver. A test sends one immediate request. Use it, together with the payload samples in Payload & help, to build your field mapping. The payload carries event metadata and the available lead, company, contact and engagement fields. Take exact field names from those samples rather than guessing.

Step 4: Map the fields into your CRM

Mapping is where most of the value is kept or lost. A sensible starting map, by payload area:

If contact fields come back empty, the lead may not have a saved email yet. traxy can request email or phone lookups for leads, including from your AI chat through the MCP, so decide whether your CRM should accept a record without an email or wait for one.

Verifying the signature and handling repeat events

Every request includes X-Traxy-Signature and X-Traxy-Timestamp headers; verify them with the signing secret as Payload & help describes, and reject anything that fails. Then make processing idempotent, because lead delivery can retry temporary failures and the same event can arrive more than once (Webhook).

Verify before you write anything

1. Keep the request body exactly as received, together with the two headers.

2. Recompute the signature with your signing secret exactly as Payload & help in the app explains.

3. Compare it with X-Traxy-Signature. If it doesn't match, return an error and stop.

4. Only then parse the JSON and continue.

Store the signing secret where your service reads secrets, not in source control. If you rotate the secret in traxy, update your receiver first, or later events will fail verification.

Make repeats harmless

The docs say lead delivery can retry temporary failures, so design for the same event twice. A receiver sketch:

on POST /traxy-leads:
  verify signature (see Payload & help) or return an error
  key = a stable identifier taken from the payload sample
  if key already processed: return success, do nothing else
  record key as processed
  if event is first delivery:
      find person by email, then by LinkedIn profile URL
      update if found, create if not
      attach the engagement fields as a note
        (post or comment, label, ICP match, if your payload sample includes them)
  if event is repeat engagement:
      find the existing person
      add the new engagement as an activity, raise priority
  return success

Two habits keep the CRM clean. Use find-or-create writes instead of plain inserts. And never create a new contact from a repeat-engagement event; that event is about someone you already have.

Handle failures on both sides

• Inspect both the delivery result in traxy and your receiver's logs.

• A route can pause after repeated failures. Fix an expired URL, an authentication failure or an unavailable service before you resume it (routes).

• Disconnecting the integration stops future delivery. It does not delete records your system already received.

Routing one saved view per destination

A route connects one audience to one destination, so build one saved view per job and give each its own route. Choose Auto delivery with an ICP match threshold for new leads, or Manual when you want to pick who goes (routes).

Add the route

1. Open the Webhook connection's Routes tab and select Add route.

2. Choose All leads or a saved view.

3. Select the webhook endpoint as the destination.

4. Choose Auto or Manual. For Auto, review the ICP match threshold.

5. Review the destination and save.

Saved views are filtered audiences in Leads that update as leads change, and routes use shared views. If you pick a personal view, saving the route shares it with the workspace, and a view a route depends on can't be deleted or made personal until you remove that dependency.

Examples of one view per destination

What Auto delivery does and doesn't do

• No backfill. Automatic routes apply to leads entering the audience from the moment you save. Saving or editing a route does not send every lead already in the view.

• Send existing leads by hand. Select them in Leads, open Send to, choose the route and check the endpoint before you confirm.

• The threshold is per destination. It controls what reaches this endpoint. It does not change qualification, which still needs a 50%+ ICP match.

• Queued is not delivered. A queued result means the request was accepted for delivery. Inspect the result to tell queued, delivered and failed apart.

• Pause, resume, delete. Use the route menu to pause or resume. Deleting a route stops future routing; leads already sent stay in your system.

Creating the destination and sending a lead from Claude

With the traxy MCP connected, you can ask Claude or ChatGPT to create a webhook destination and then queue a selected lead for delivery to it. The AI should confirm the host, the audience and the destination with you first, because a webhook sends contact data outside traxy.

Connect the MCP once: under Integrations, pick your client, add https://api.traxy.ai/api/v1/mcp, sign in, pick workspaces and approve. No API key is needed (connect an AI client). The public MCP tool catalog then includes these integration tools (MCP tools):

A typical exchange: "Create a webhook destination called CRM intake for https://crm.example.com/traxy-leads." Your AI shows what it will create and waits for your yes. Then: "Send the lead who commented on yesterday's pricing post to CRM intake." The AI finds the lead, queues it and reads the delivery state back, because a queued delivery is not proof of completion and the docs say to read the resulting state before repeating a request.

The same tools also cover Clay, n8n and Zapier destinations. Each tool lists its required scopes, and your role and workspace access still apply, so check tools/list for what your connection can use. The in-app agent, trax, has some capabilities the public MCP doesn't, so use the public catalog rather than assuming every app action has an MCP equivalent (API and MCP).

Should traxy run the outreach instead of your own system?

If the reason you're pushing leads is to start outreach, traxy can run the LinkedIn and email outreach itself from your own connected sender accounts, so you don't need to rebuild sequencing. Keep the webhook for CRM records and reporting either way.

In traxy, a campaign takes a shared view as its audience, researches each lead for the facts you ask for, groups leads by signal and prepares a personalized message variant for each group across LinkedIn and email. You test the plan on sample leads with nothing sent, then read the launch review: who joins, who is skipped (held by another campaign or contacted before), the sender, the steps and the delivery mode. Nothing sends until you approve the launch. After that the campaign runs on its own, or you approve each message in a review queue. Replies, unsubscribes and hard bounces stop the sequence, and conversations land in one inbox (LinkedIn outbound).

You can run many campaigns at once on different signals, by hand in the app, through trax, or from the traxy MCP in Claude or ChatGPT, where the AI asks for your yes in chat before anything launches or sends. Sending needs connected sender accounts: LinkedIn accounts and mailboxes you add under Settings.

When your own outreach system is the better choice: you already have deliverability, sequencing and reporting you don't want to move, or the leads feed a channel traxy doesn't send on. In that case route a view to your system and let traxy do the finding and qualifying.

Limits to know before you build

• HTTPS only. The webhook needs an HTTPS endpoint that accepts requests outside a temporary test session.

• No automatic backfill. Auto routes send leads that enter the view after you save. Send existing leads with Send to.

• Repeats can happen. Delivery can retry temporary failures, so your receiver must be idempotent.

• Routes can pause. Repeated failures can pause a route until you fix the receiver and resume it.

• REST reads only. The REST API reads leads, signals, tracked profiles, analytics and meetings. It doesn't push leads or send messages.

• Contact data needs permission. Through REST, contact fields and profile URLs are redacted unless the key has leads:contact_read. MCP delivery tools also list leads:contact_read among their required scopes.

• No promise beyond the docs. The docs don't publish a retry schedule or a delivery-time guarantee, so don't build logic that depends on one. Check the delivery result instead.

FAQ

Does traxy have a webhook for new LinkedIn leads?

Yes. The Webhook integration sends signed lead events to any HTTPS endpoint: a first-delivery event when a qualified lead reaches the destination and a repeat-engagement event when a known lead engages again. A route decides which leads go there (Webhook).

Can I send traxy leads to a custom or in-house CRM?

Yes. Put a small HTTPS receiver in front of your CRM, connect it as a webhook in traxy, and route a saved view to it. Your receiver verifies the signature, de-duplicates and writes through your CRM's own API.

Which headers does traxy send?

Each request includes X-Traxy-Signature and X-Traxy-Timestamp, plus the authentication header you configured, if any. Payload & help in the app explains how to verify the signature with the signing secret.

Will leads already in my view be sent when I add a route?

No. Automatic routes apply to leads entering the audience from that point on. To send existing leads, select them in Leads, open Send to and choose the route.

Why did the same lead arrive twice?

Either delivery retried after a temporary failure, or the second event is a repeat engagement from the same person. Check the event type, and key your writes on a stable identifier from the payload so repeats don't create duplicates.

Can I pull leads with an API instead of a webhook?

Yes. Create an API key under Integrations and read leads, signals and engagements from https://api.traxy.ai/api/v1. See the LinkedIn leads API guide for endpoints, filters and paging.

Can I set up the webhook from Claude or ChatGPT?

Yes. With the traxy MCP connected, your AI can create a webhook destination, create a delivery route and queue a selected lead, after confirming the host, audience and destination with you (MCP tools).

Does the webhook work with Zapier, n8n or Clay?

traxy has separate Zapier, n8n and Clay integrations that use the same routes. See the guides for Zapier, n8n and Clay. For every destination traxy can send leads to, from Slack to a Meta audience, see where to send qualified LinkedIn leads from traxy.

Which leads end up in the webhook?

Only qualified leads: people found from LinkedIn social intent with a 50%+ ICP match, each with the post or comment behind them. A route's own threshold can narrow that further for one destination.

Do I still need my own outreach tool?

Not necessarily. traxy runs LinkedIn and email outreach from your own connected accounts, on autopilot once you approve the campaign, or you approve every message. Use your own system when you want to keep sequencing there (LinkedIn outbound).

Next step

Stand up a receiver that logs the raw request, connect it under Integrations > Webhook in traxy, send a test payload and build your mapping from it. Then save one view, add a Manual route, send three leads with Send to and check them in your CRM before you switch the route to Auto.