What this API does and who it is for

The LinkedIn Sales Navigator Scraper API sits as a proxy layer between your application and LinkedIn's Sales Navigator product. Instead of purchasing and managing Navigator seats yourself, you send POST requests to this API and receive structured people or company records in return. The provider maintains Navigator accounts on the backend and routes your queries through them.

The primary audience is anyone building B2B lead pipelines at scale: sales automation tools, CRM enrichment services, recruiting platforms, or internal data teams. If your use case is a one-off research task, the free tier's 20 requests per month will not get you far — this API is designed for continuous, high-volume extraction workflows where paying per seat would be prohibitively expensive.

Endpoint walkthrough

All 25 endpoints accept POST requests. The surface area breaks cleanly into two groups.

Core search endpoints

The four primary endpoints do the heavy lifting:

  • /premium_search_person — runs a lead search with filters you supply in the request body, equivalent to LinkedIn Sales Navigator's People search.
  • /premium_search_company — runs an account/organization search.
  • /premium_search_person_via_url — accepts a Sales Navigator search URL instead of a structured JSON body, useful if you are already generating URLs from the Navigator UI.
  • /premium_search_company_via_url — the same URL-based approach for company searches.

There is also a /search_suggestions endpoint and a /json_to_url utility that converts a filter JSON payload into a Navigator-compatible URL, which can simplify debugging or allow you to share searches with colleagues who use the Navigator UI directly.

Filter suggestion endpoints

The remaining 20 endpoints all follow the pattern /filter_<dimension>. They return valid filter values for dimensions like geography (region and postal code), job title, industry, seniority level, company headcount, department headcount, annual revenue, technology stack, school, company type, Fortune ranking, languages, followers count, years in role/company, recent activities, and job opportunities.

These are not optional niceties — you need them to build correct filter payloads for the search endpoints. LinkedIn Sales Navigator filters use internal IDs, not plain strings, so calling /filter_industry_suggestions or /filter_job_title_suggestions first is a practical prerequisite for precise searches.

Pricing and realistic lead volumes

The API uses a freemium billing model with four tiers.

Plan Monthly price Included requests Overage Backend accounts ~Leads/day ~Leads/month
BASIC $0 20 minimal minimal
PRO $150 30,000 $0.001 1 25,000 750,000
ULTRA $300 60,000 $0.001 2 50,000 1,500,000
MEGA $450 90,000 $0.001 3 75,000 2,250,000

The CUSTOM plan scales linearly: each additional Navigator account adds one tier's worth of capacity.

A few things worth understanding about the numbers. The provider distinguishes between API requests (the billing unit) and leads returned (the data volume unit). Each search call can return a batch of leads, which is why the PRO plan's 30,000 monthly requests translates to roughly 750,000 lead records per month. The per-day quota — approximately 1,000 calls to /premium_search_person and 1,000 calls to /premium_search_company per backend account — is enforced independently for each endpoint, not shared.

Overage on paid plans is billed at $0.001 per request. At that rate, exceeding the PRO cap by 10,000 requests adds $10 to your bill, which is manageable but worth monitoring.

Key operational constraints

Success rate and latency. The API reports a 90% average success rate and 1,395 ms average latency. A 10% failure rate is meaningful in production; your integration should handle retries gracefully and avoid treating a failed call as a data absence.

Rate-limit freeze. When LinkedIn returns a 429 (Too Many Requests) response — which can happen if you send malformed requests or exceed LinkedIn's own internal thresholds — the provider freezes the affected backend account for 60 minutes. During that window, requests routed through that account will fail. On the PRO plan with a single backend account, this means a 60-minute outage for all your searches. On ULTRA or MEGA, other accounts remain available. If uptime continuity matters, consider whether the multi-account plans justify the cost.

No dedicated auth documentation. The readme notes that GET endpoint parameters are documented inline and POST endpoint guidance comes from the request body schema. There is no published authentication flow in the provided data, so you will need to rely on marketplace-level credentials (typically an API key header) and the inline docs.

Terms of service risk. Scraping LinkedIn — even through a proxy — sits in a legally and contractually ambiguous space. LinkedIn's terms prohibit automated data extraction. This does not mean the API is unusable, but you should understand the risk profile before building a production system on top of it.

Practical use cases

  • Outbound sales tooling: Build a pipeline that queries /premium_search_person with seniority, geography, and industry filters, then feeds results into a CRM or sequencing tool.
  • Market sizing and segmentation: Use /premium_search_company with headcount, revenue, and technology filters to generate account lists for specific verticals.
  • Lead enrichment services: Accept a Sales Navigator URL from a sales rep, pass it to /premium_search_person_via_url, and return structured data without the rep needing API knowledge.
  • Filter catalog caching: Call the 20 filter endpoints once to build a local lookup table of valid IDs, so your application can translate human-readable inputs (e.g., "Software Development" as an industry) into the correct filter values without a live API call per request.

Getting started

The BASIC plan's 20 free requests are enough to validate your request format and confirm the response schema fits your data model, but not enough for a meaningful volume test. Plan to upgrade to PRO quickly if the integration proves viable. When building your first search call, use the filter suggestion endpoints to retrieve valid IDs before constructing the main search payload — this is the most common source of failed or empty results. Implement a 60-minute backoff handler from day one so that LinkedIn-triggered freezes do not cascade into application errors.