LinkedIn signals API — trigger your pipeline on real LinkedIn events
A LinkedIn signals API should behave like a message bus, not a CSV: job changes, new hires, and account moves arrive as webhooks your systems can react to the moment they happen. Edges turns LinkedIn into an event stream for sales engineering, RevOps, and the AI agents now running large parts of outbound.
If your team searches for a LinkedIn intent API, LinkedIn job change alerts API, or LinkedIn buying signals API, this page covers the shape, the cadence, and the integration pattern we recommend for production.
Most go-to-market stacks still enrich data on a weekly cron. A worker pulls the open opportunities on Sunday night, decorates them with fresh titles and headcount, and drops the result back into Salesforce before the Monday standup. That rhythm was fine when pipelines were slow. It is not fine when the VP you have been selling to changed jobs on Tuesday, interviewed at a competitor on Wednesday, and announced the move on Thursday—while your SDRs spent the week writing sequences to the old email address.
A LinkedIn intent API flips that default. Instead of re-enriching the world on a schedule, you register the entities you care about, describe the change you want to hear about, and let the provider push events when those changes happen. The same underlying data powers both modes, but the operational shape is different. Static enrichment is a table. Signals are a queue.
The audience converging on this pattern is specific. Sales engineering teams want to collapse the gap between an event on LinkedIn and a routing decision in their CRM. RevOps leaders want to retire the home-grown cron jobs that drift every time LinkedIn ships a layout change. Product teams building AI sales agents need a dependable source of triggers—something sharper than a weekly list upload—so their agents spend compute on deciding what to say, not on guessing whether anything has changed. Recruiting platforms want to surface candidates on the day their tenure crosses a threshold, not a month later.
Edges treats the LinkedIn graph as a set of monitored entities with subscribable deltas. For the product philosophy behind this, read the intent economy essays. For how signals fit beside people and company enrichment, see the enrichment API and the LinkedIn scraper page. Implementation details live in the documentation.
{
"event": "linkedin.job_change",
"detected_at": "2026-04-21T14:02:11Z",
"subject": {
"linkedin_profile_url": "https://www.linkedin.com/in/jane-doe",
"full_name": "Jane Doe"
},
"change": {
"previous": {
"job_title": "Director of Product",
"company_name": "Acme Corp"
},
"current": {
"job_title": "VP Product",
"company_name": "Northwind"
}
},
"monitor_id": "mon_01H...",
"confidence": 0.97
}Events are diffs—previous and current state, detection timestamp, confidence score.
Why intent beats static data
Weekly CRM enrichment answers the wrong question. It tells you what is true at the end of the week, not which records changed and why. That means you enrich after the event you care about has already shaped the buying cycle—after the new VP has picked a vendor, after the hiring surge has already been posted, after the champion has left for a competitor without a forwarding address.
LinkedIn company signals and person-level deltas are the opposite: they are small, addressable, and timestamped. You do not get a 200-column table; you get one event, identifying which record, what changed, and when the change was detected. That is enough to route, score, or trigger an outbound cadence without rerunning your entire enrichment job.
- Each event carries previous and current state so downstream logic can branch on the diff.
- Monitors scope the firehose to entities you care about—CRM accounts, a target list, a watchlist.
- Delivery is push-first, so you do not rebuild a scheduler on top of a polling endpoint.
curl -X POST \
"https://api.edges.run/v1/monitors" \
-H "Content-Type: application/json" \
-H "X-API-Key: <YOUR_API_KEY>" \
-d '{
"type": "linkedin-job-change",
"scope": {
"linkedin_profile_urls": [
"https://www.linkedin.com/in/jane-doe",
"https://www.linkedin.com/in/alex-rivera"
]
},
"delivery": {
"mode": "webhook",
"url": "https://hooks.yourapp.com/edges/job-change"
}
}'One call to register the monitor. Events arrive on your endpoint as they happen.
What Edges tracks
The LinkedIn graph has a lot of moving parts. Edges exposes the ones that actually map to pipeline action:
- Job changes and role moves — promotions, departures, and lateral moves on people you already know, including your current customers.
- New hires at target accounts — the first VP Engineering, the first Head of RevOps, the first Director of Data—roles whose existence is itself a signal.
- Profile and engagement activity — posts, comments, and reactions from watched profiles so you can catch intent that lives in public behavior.
- Company moves — headcount swings, funding mentions, and narrative changes on the company page.
- Sales Navigator metric changes — saved-search result deltas and tracked-list movements, normalized into events instead of raw HTML.
- Custom keyword monitors — a keyword appearing in a bio, a headline, or a job description on any entity in scope.
This covers the signals our customers ask for most, and the moves your team defines next. If you have a specific event shape in mind—an IPO watch, a product launch mention, an internal transfer pattern—bring it to a demo and we will map it to monitors you can deploy.
Every event we emit is tied back to a specific LinkedIn entity and a specific monitor, so downstream systems can attribute actions cleanly. When an account manager asks why did the CRM open a task on this account?, the answer is a monitor ID, an event timestamp, and a diff—not a guess about which vendor synced what overnight. That audit trail is the difference between signals people trust and signals people silently ignore.
When teams reach for signals
Four patterns we see repeatedly in production stacks. All of them break under weekly batch enrichment.
AI SDR agents that need real triggers
Autonomous outbound agents do not struggle with writing copy—they struggle with reasons to write. A job-change event or a new-hire signal is a clean prompt: who, what changed, when. The agent composes the context-aware message and calls back into Edges messaging actions to send it. The LinkedIn buying signals API replaces the cold list with a live queue.
Account-based marketing triggers
ABM plays get stale fast when the account object does not reflect reality. Wire signals into your campaign router so a new hire at a target account spins up the right play automatically—no quarterly list refresh, no Slack thread asking who owns the update.
Recruiting auto-outreach on job changes
Sourcing platforms embed the LinkedIn job change alerts API to surface candidates whose tenure just hit a trigger window—18 months, 24 months, a recent promotion. The recruiter sees a ranked queue of people most likely to take a call, not a static long-list scraped last month.
Churn prevention on customer job moves
When a champion leaves a customer account, CS has a narrow window to build a new relationship before renewal risk compounds. A webhook into your CS platform opens a task the same day the move is detected, instead of during the quarterly health review.
Webhooks versus polling—when to choose which
Webhooks—product-embedded, real-time
If signals are driving a user-visible feature—an AI agent, an in-app inbox, a task queue for a recruiter—webhooks are the default. You get a push the moment an event fires, with retries and signed payloads so your ingestion endpoint can verify origin.
Operationally, this means one dead-letter queue, one replay tool, and one set of alarms on your side. The rest of the orchestration happens on Edges.
Polling—warehouse-native, reconciled
Some stacks prefer to pull. Data teams running dbt on top of Snowflake or BigQuery often want signal events as a table that lands on their schedule, so the rest of the model graph stays consistent. A LinkedIn activity API call against the events endpoint returns what changed since the last cursor, and you append to your fact table.
Mixed mode is fine too: webhooks for the hot path into product, polling for the warehouse mirror that analysts query.
Signals are the product. The intent economy is the thesis.
Two things sit next to each other at Edges and occasionally get conflated. The signals API is a product with endpoints, quotas, SLAs, and a pricing model. The intent economy is our public essay on why revenue stacks are shifting from static lists to event-driven pipelines. If you want the argument, read the essay. If you want the implementation, this page and the docs are the right starting point.
Teams comparing vendors usually also look at firmographic feeds. We maintain a side-by-side at compare/crustdata and a broader compare hub for the rest of the landscape. Short version: firmographic data is a snapshot, signals are a stream, and most real stacks use both.
When you ship this to production, the integration tends to settle into a small set of primitives. Monitors are declared in code or in a config file your deploy pipeline manages. Webhook endpoints are owned by whichever service actually acts on the event—your router, your CS platform, your agent runtime. Dead-letter handling, replay, and idempotency live on your side, same as any other critical webhook producer. The rest of the Edges action library stays available for the followups a signal tends to trigger: a deeper profile lookup, a company enrichment to fill in the new employer, a messaging action to send the outbound. One API key, one billing line, one set of docs for the whole flow.
LinkedIn signals API FAQ
Straight answers for the queries people pair with linkedin signals api and linkedin intent api in search.