Break a search past the 2,500-row ceiling

One search too big for LinkedIn, covered by many smaller ones.

LinkedIn serves 2,500 rows of any search however many match it. A search with 40,000 people in it is not one request away from being answered - it is answered by running a set of NARROWER searches that between them cover the same people. This works out which, and then runs them.

It plans first, and you approve the plan. The batch counts your search, works out which filter actually divides it, and splits it into as few pieces as the 2,500-row ceiling allows - recursing on whatever is still too big. The first result entry is the quote: how many shards, how many rows each, what fraction of the search they reach and what the rest will cost. Nothing else runs until you POST /batches/{id}/approve - or until a plan clears the auto_approve_coverage you named up front.

The shards union back to your search. A filter you constrained is subdivided within YOUR values; a filter you left open is partitioned across all of its, one shard often carrying several values at once. Nothing is ever narrowed by a value you did not ask for. That is the difference between this and bolting two filters onto a search and hoping - the tools that do the latter hand back a different population from the one you described.

Coverage is measured rather than promised. Where a filter's values sum to less than the search they came out of, the difference is people LinkedIn cannot classify on that filter - a profile with no dates on its current position, against a tenure filter. Every one of them is counted, on the branch that lost it, and reported under residuals.

Most of them are then recovered. LinkedIn accepts an exclusion on the function and seniority filters, so where you left either open, "none of these values" is a real search naming exactly the people that filter could not place - and it becomes another shard rather than a shortfall. Those two are preferred wherever they divide a search at all, because a split on them loses nobody. Expect the high nineties on a broad search, and less on one whose own filters have already settled the useful ones - a search for a single job title has decided its function and very nearly its seniority, and what is left to split on leaks.

The price is every other search's: 50 credits a request, and both halves are requests. A count is one and a page is one, so there is no premium for the breaking and nothing here you cannot derive.

Request #

Call it #

curl -X POST "https://api.easydata.win/v1/sales/search/deep" \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"targets":[{"searchUrl":"https://www.linkedin.com/sales/search/people?query=(filters:List())"}],"max_results":40000,"auto_approve_coverage":0.8}'

Response #

{
  "data": {
    "batch_id": "afec9131-080b-4b96-b3bb-726249e4bbf8",
    "operation": "sales.search.deep",
    "status": "queued",
    "total": 2,
    "succeeded": 0,
    "failed": 0,
    "pending": 2,
    "results_available": 0,
    "credits_used": 0,
    "external_id": "crm-sync-2026-09-01",
    "created_at": "2026-09-01T10:00:00Z",
    "completed_at": null,
    "recommended_poll_ms": 2000
  },
  "meta": { "requestId": "req_8f2ka91x", "recommendedPollMs": 2000 }
}

A result entry #

Once the batch has drained, this is what reading its results gives you.

{
  "item_index": 0,
  "page": 1,
  "input": { "searchUrl": "https://www.linkedin.com/sales/search/people?query=(filters:List())" },
  "status": "succeeded",
  "credits_used": 2300,
  "data": {
    "plan": {
      "total": 41208,
      "reachable": 37940,
      "coverage": 0.9207,
      "probes": 46,
      "requests": 434,
      "budget_exhausted": false,
      "shards": [
        {
          "pins": [{ "axis": "FUNCTION", "label": "Function", "value": "25", "text": "Sales" }],
          "rows": 1962,
          "capped": false
        },
        {
          "pins": [
            {
              "axis": "COMPANY_HEADCOUNT",
              "label": "Company headcount",
              "value": "",
              "text": "Self-employed, 1-10, 5,001-10,000",
              "values": [
                { "value": "A", "text": "Self-employed" },
                { "value": "B", "text": "1-10" },
                { "value": "H", "text": "5,001-10,000" }
              ]
            }
          ],
          "rows": 1968,
          "capped": false
        },
        {
          "pins": [
            {
              "axis": "SENIORITY_LEVEL",
              "label": "Seniority",
              "value": "",
              "text": "not classified",
              "excluded": true
            }
          ],
          "rows": 412,
          "capped": false
        }
      ],
      "residuals": [
        {
          "axis": "FUNCTION",
          "label": "Function",
          "pins": [],
          "rows": 2104
        }
      ]
    },
    "approved": false,
    "harvest_credits": 19400,
    "expires_at": "2026-09-23T10:00:12Z"
  },
  "created_at": "2026-09-21T10:04:11Z"
}

Errors #

Every failure uses the same envelope, and none of them is metered - see Errors.