Sales Navigator API for revenue tools
A Sales Navigator API should feel like any other backend dependency: call an endpoint, get typed JSON, paginate, move on. Edges exposes Sales Navigator saved searches, lead lists, account lists, smart links, and lead and company search behind one REST API — the same key and credit pool as our enrichment, messaging, and signals actions.
Built for product engineers shipping ABM platforms, AI SDRs, recruiting tools, and CRM plugins that have outgrown operator-facing Chrome extensions.
Sales Navigator is where the best B2B intent data lives — curated people and account filters, saved searches refreshed against a live graph, lead lists and account lists that your sales team already maintains, and smart links that track engagement with shared content. Most tools that let you get that data out are aimed at the operator sitting in front of the UI. That is fine if your job is running a list every Tuesday. It is not a viable foundation if you are building a product that needs Sales Nav data hourly, across many customer tenants, behind a real backend.
That is the gap Edges fills. We are a Sales Navigator scraper API in the sense that we handle the upstream complexity — sessions, pagination, shape normalization — and hand you JSON your service can trust. But scraper is the wrong mental model. You are not maintaining selectors; you are calling an endpoint with a URL or a list ID and getting structured rows. Reliability, observability, and versioning are our problem, not yours.
If you are building revenue infrastructure and need Sales Navigator data flowing into your own product, this is the pillar page for you. Below: where operator-first tools break down, what the Edges Sales Navigator surface actually covers, a code sample you can copy today, and the consolidation math when Sales Nav sits next to enrichment and signals under one vendor. Implementation details live at docs.edges.run; endpoints and credit costs live in the action library.
curl -X POST \
"https://api.edges.run/v1/actions/salesnavigator-extract-leads-list/run/live" \
-H "Content-Type: application/json" \
-H "X-API-Key: <YOUR_API_KEY>" \
-d '{
"input": {
"salesnavigator_leads_list_url": "https://www.linkedin.com/sales/lists/people/..."
}
}'Same action your batch jobs use: salesnavigator-extract-leads-list— pass the list URL, paginate, done.
Most Sales Navigator tools are built for the operator, not the backend
The vast majority of Sales Navigator extraction tools — Chrome extensions, in-browser exporters, standalone desktop apps — assume a human is sitting in front of Sales Navigator pressing a button. That shape is fine for an SDR cleaning up a weekly list. It is hostile to a backend job that needs fresh data for every account in a customer's CRM, across hundreds of tenants, without anyone babysitting an exporter.
- Extension tools couple your data flow to a logged-in browser tab on a laptop.
- Per-lead or per-export exporters require humans to trigger runs — your product cannot schedule them.
- Desktop exporters rarely expose a clean schema, so you parse CSV blobs instead of consuming JSON.
- Multi-tenant SaaS simply cannot be built on a tool designed for one seat and one browser session.
A Sales Navigator leads API flips that model. Your service calls the endpoint, the endpoint returns rows, and scaling concurrency is a matter of scaling workers, not hiring another SDR to click export. Engineers who have tried to build a commercial product on top of Lobstr, Evaboot, PhantomBuster flows, or a homegrown Puppeteer script eventually hit the same wall: reliability is a feature of your vendor, and your vendor's shape determines whether the feature is even available to you. An API-first vendor has to take that reliability on; an operator-first tool never has to.
[
{
"full_name": "Alex Rivera",
"job_title": "Head of Growth",
"company_name": "Acme Corp",
"salesnavigator_profile_url": "https://www.linkedin.com/sales/lead/...",
"linkedin_profile_url": "https://www.linkedin.com/in/alex-rivera",
"location": "Austin, TX",
"list_id": "7093..."
},
{
"full_name": "Sam Chen",
"job_title": "Director of Sales",
"company_name": "Northwind",
"salesnavigator_profile_url": "https://www.linkedin.com/sales/lead/...",
"linkedin_profile_url": "https://www.linkedin.com/in/sam-chen",
"location": "Seattle, WA",
"list_id": "7093..."
}
]Rows keyed by SN profile and list ID — ready to upsert into your CRM or warehouse.
What Edges exposes on the Sales Navigator surface
Sales Navigator is a first-class surface for Edges. We focus on the primitives revenue tools actually need — the ones you would otherwise build yourself on top of a brittle browser automation stack.
- Saved searches — run a saved people or company search by URL, paginate through results, and track search metrics over time. This is the core Sales Navigator saved search API request.
- Lead lists — dump a full lead list as JSON, keyed by SN profile ID and list ID. Keep customer lists synced with your product without anyone opening Sales Nav.
- Account lists — the same pattern for account lists, with company-shaped rows your account data model can consume directly.
- Lead and company search — paginated search across people and companies, plus company-level employee counts and distribution for account planning.
- Smart links and account maps — fetch account-level signals and company detail views so you can build account plans programmatically.
For the full action catalog — including credit cost per call — see the library.
curl -X POST \
"https://api.edges.run/v1/actions/salesnavigator-search-people/run/live" \
-H "Content-Type: application/json" \
-H "X-API-Key: <YOUR_API_KEY>" \
-d '{
"input": {
"salesnavigator_people_search_url": "https://www.linkedin.com/sales/search/people?...",
"page": 1
}
}'Paginate with the page field; wrap in an async run for long exports and receive a webhook on completion. See docs.edges.run for the full async pattern.
From saved search URL to structured rows in one call
The ergonomic bar for a good Sales Nav endpoint is simple: hand it a URL, get back a paginated array of typed rows. Edges keeps that contract. Point salesnavigator-search-people at a saved people search URL and you get pages of people rows — name, job title, company, profile URL, location. Same shape for company-side searches, same shape for lead and account lists. Your worker code does not have to care which primitive it is consuming.
If you need to go deeper — full profiles, full company records, employee distributions — chain into linkedin-extract-people and linkedin-extract-company using the IDs the search returned. One request contract, one credit pool, one set of error codes.
If you are newer to the surface itself and want a primer on what filters Sales Nav exposes, our guides on advanced search filters and Sales Nav best practices map the UI to what you will eventually automate.
When teams reach for a Sales Navigator API
The pattern is consistent: a product team owns a data flow that cannot sit behind a human pressing export. They move from an internal scraper stack or a piecewise set of browser extensions to a single API because the business logic downstream demands predictable inputs — not CSV files that showed up whenever a teammate had time to run them.
ABM platforms feeding their UI with live SN data
Customers link their own Sales Navigator seat, the platform keeps saved searches and account lists synced in the background, and the product UI renders fresh rows without an operator exporting anything. The API is the sync layer.
AI SDRs enriching pipeline hourly
Agents pick the next cohort to work, pull the underlying Sales Nav lead list, enrich every profile, and decide the next action — all on a schedule the agent controls. A Chrome extension cannot participate in that loop; an API can.
Recruiting tools running saved searches
Sourcing products keep a library of saved people searches per role, re-run them nightly, and surface new candidates in the ATS. LinkedIn Sales Navigator automation is the recruiting team's force multiplier — as long as it is wired into their pipeline, not their laptop.
CRM plugins keeping SN lists in sync
Salesforce and HubSpot add-ons that surface Sales Nav lists next to opportunities need a backend sync, not a one-off export. The API reads list membership, pushes it into CRM custom objects, and runs again on a schedule your admin controls.
One API key, one credit pool for SN, enrichment, and signals
The competitors silo this. A Sales Nav extraction tool bills you for exports, an enrichment vendor bills you per profile, a signals vendor bills you per event. Three contracts, three credit models, three different error codes to handle. When your workload shifts — more enrichment this quarter, more SN next quarter — you renegotiate three times.
Edges runs Sales Navigator alongside enrichment, signals, and the rest of the LinkedIn Actions catalog on one credit balance. Credit cost per action is published in the library; your mix can drift without ripping out a vendor. That is the consolidation story in one line: stop paying three vendors to assemble the workflow you want.
Enterprise buyers who need SOC2 Type II, a signed DPA, and EU data handling are on the same posture — see the enterprise track.
How this differs from Lobstr, Evaboot, and the rest
Lobstr is an operator UI — you log in, configure a crawler, and download results. Fine for an SDR, wrong mental model for a backend. Evaboot is a per-lead exporter tied to a Chrome extension — fine for cleaning up one list, wrong for a SaaS product that needs programmatic access across many customers. Edges is the developer API tier: a REST contract, webhooks, SDKs, versioned payloads, and the same auth as the rest of Edges.
If a human is the primary user, an operator tool may still be the right answer. If a service is the primary consumer — an ABM platform, an AI agent, a CRM plugin, a recruiting tool — you want an API and you want the vendor to own upstream reliability. For a deeper head-to-head, see our Edges vs Lobstr comparison and the broader Compare hub.
None of this removes your obligation to use Sales Navigator within LinkedIn's terms and your own customer contracts. What changes is technical ownership: you stop maintaining a browser farm and start consuming an endpoint you can monitor like any other service.
Sales Navigator API FAQ
Straight answers for the questions product and platform teams ask before wiring Sales Nav into a backend.