LinkedIn Scraper
Search Services
Search LinkedIn service-provider listings (freelance/agency services) by keyword.
1 creditNo API key neededEndpoint
Parameters
| Name | Type | Required | Note |
|---|---|---|---|
| searchstring · required | string | required | Service to search for, e.g. "web development". A multi-word term is matched as a phrase, so it will not pull in every provider who happens to mention both words. Separate several services with COMMAS to match any of them — "web development, mobile apps" is sent as an OR of the two exact phrases. Boolean syntax is passed through untouched if you prefer to write it yourself. Example: |
| limitnumber · optional | number | optional | Max number of services to return (1-1000). Default: 100. Each page returns up to 10 services, so a smaller number here also means fewer pages scraped. Default: Example: |
Response schema
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"elements"
],
"properties": {
"hasMore": {
"type": "boolean",
"description": "True only when the provider still had reachable data and this execution stopped early. A managed Agent must treat this as an incomplete batch, never as completion."
},
"elements": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"services": {
"type": "array",
"items": {
"type": "string"
},
"description": "The provider's LinkedIn service categories"
},
"linkedinUrl": {
"type": "string"
}
},
"additionalProperties": true
}
},
"nextPage": {
"type": "integer",
"exclusiveMinimum": 0
},
"returned": {
"type": "number",
"description": "How many records this run returned, after any `limit` was applied. ONE EXCEPTION: on a chat preview — where `truncated` is true — this is the count actually FETCHED while `elements` carries only a short sample of them, so the two deliberately disagree. Read `truncated` before comparing this against the array length; in a workflow it is never set and the two always match. Matches the other LinkedIn data tools, whose `meta.returned` is the fetched count on a truncated preview too."
},
"truncated": {
"type": "boolean"
},
"stopReason": {
"enum": [
"cancelled",
"provider-error",
"empty-page-stall",
"caller-limit",
"presentation-preview",
"cursor-stall",
"runtime-page-window",
"time-budget"
],
"type": "string"
},
"suggestion": {
"type": "string"
},
"totalCount": {
"type": "number",
"description": "How many records the search MATCHES, per the provider — the grand total, routinely in the millions while the endpoint will only serve about a thousand of them. Do NOT compare it with the row count to decide whether a run was complete, and do not paginate towards it: use `servableCount` for what is actually reachable. Absent when the provider sent no count."
},
"totalPages": {
"type": "number"
},
"pagesScraped": {
"type": "number"
},
"servableCount": {
"type": "number",
"description": "How many records this endpoint will serve across all its pages — the real ceiling on what any number of runs can reach, which the provider caps well below `totalCount` on most search endpoints. Absent when the provider sent no count."
},
"totalElements": {
"type": "number",
"description": "DEPRECATED — despite the name this is the count RETURNED by this run, not a grand total, so it equals your `limit` on a limited run. Kept at that value so existing flows do not change meaning. Use `returned` for this number, `totalCount` for how many records match, or `servableCount` for how many are reachable."
},
"nextPaginationToken": {
"type": "string"
}
},
"additionalProperties": true
}
