List people at a LinkedIn company

Returns a paginated list of members who work at a company, with handle, headline, location, and member URN. Get the company_id from /v1/linkedin/company. Each page is 10 members. On a plain call author.followers is LinkedIn's rounded display bucket, and only on the rows that show one (flagged author.ext.followers_approximate: true), and author.following is null on every row. When the primary source is momentarily rate-limited on page 1, a second source answers that page with current members of the same company in a different order and with exact follower counts (author.ext.followers_approximate: false), and data._warnings says so; page 2 onwards always comes from the primary, so a member can repeat or be missed across that boundary. Send include=profile and every row is joined, in the same call, to the member's profile lookup (/v1/linkedin/profile): author.followers becomes the exact follower count and author.ext.followers_approximate reads false on every row the lookup filled, whether the row arrived with LinkedIn's rounded bucket or with no count at all, author.following is filled with the member's connection count (on LinkedIn a member's following is the number of connections), and the location, the joined date (author.joined_at), and the country, website, cover image and profile flags on author.ext land where the row lacks them. Cost: 10 credits for the list; include=profile holds 4 credits per row and keeps only the rows filled from a fresh lookup, so a call costs at most 50; rows already in cache are free and unfilled rows are refunded. Pass limit (1 to 10) to join only the top rows: limit=3&include=profile costs at most 22. Time: the lookups run in parallel, about 1 second for 10 rows, up to 3 on a slow second, and never more than 8 seconds. The response carries a hydration block itemising rows, lookups, cache hits, credits and milliseconds.

get/linkedin/company/people

Request

Base URL: https://www.socialcrawl.dev/v1
URL: https://www.socialcrawl.dev/v1/linkedin/company/people
Auth: API key in header x-api-key

Query parameters

company_idstring required

LinkedIn numeric company ID (from /v1/linkedin/company).

pageinteger

Page number for pagination (default 1). Native upstream cursor param. Send the universal cursor instead: the API maps it to this name for you.

include'profile'

Set to profile (one token only) to join every row to the member's profile lookup in this one call: author.followers becomes the exact count and author.ext.followers_approximate reads false on every row the lookup filled, author.following is filled with the member's connection count, and the location, joined date, country, website, cover image and profile flags land where the row lacks them. Holds 4 credits per row and keeps only the rows filled from a fresh lookup; rows already in cache and rows that could not be filled are refunded, so a call costs at most 50 (10 + 4 per row) and the usual bill is lower. Adds about 1 second for 10 rows, up to 3 on a slow second and never more than 8, and nothing when the members are already cached; read data.hydration for the rows, the credits held and kept, and the time.

limitinteger

Take the top N rows of this page (1 to 10). With include=profile it caps both the rows joined and the extra credits: limit=3&include=profile costs at most 22. The page cursor still advances past the full page of 10, so the rows past your limit are skipped, not carried to the next page. Without include=profile the call stays 10 credits.

cursorstring

Universal pagination cursor. Send pagination.next_cursor from the previous response back verbatim: the API maps it to this endpoint's native page (page style). You never construct, decode, or look up a cursor. Omit it for page 1.

Headers

Cache-Controlstring

Send no-cache to bypass the response cache and force a live fetch. Billed at the normal endpoint cost; the fresh result is written back to cache for the next caller. Only the no-cache directive triggers this. See the Response Schema guide for details.

Idempotency-Keystring

Optional UUID that makes the request safely retriable. The key is reserved atomically per account before billing. A concurrent retry receives 409 IDEMPOTENCY_IN_PROGRESS with a Retry-After of 1 second while the original is young, growing to a quarter of the time it has been running (at most 30); a crashed reservation expires after 5 minutes. A replay keeps the cached payload immutable except for billing metadata: credits_used becomes 0, idempotent_replay becomes true, and credits_remaining is refreshed to the current balance. A known current balance appears in both the body and X-Credits-Remaining header; no balance row resolves to 0. On a transient lookup failure, body credits_remaining is null and X-Credits-Remaining is omitted. Completed outcomes expire after 24 hours. If the claim store is unavailable, the request fails closed before billing. GET endpoints do not combine idempotent replay with Server-Sent Events: use Accept: application/json when sending this header. The unsupported key-plus-SSE combination is rejected before billing.

Response

Successful response

successboolean required

Whether the request succeeded

platformstring required

Platform name

endpointstring required

API endpoint path

credits_usedinteger required

Number of credits consumed

credits_remaininginteger nullable required

Current account balance, or null when this response could not establish one. Free cache hits always return null because they do not establish an authoritative post-request balance. An idempotency replay also returns null when its current-balance lookup fails. It is never a fabricated zero, so a zero here means the account really is empty. The authoritative reading is the one on a billed response, which comes straight from the deduction.

request_idstring required

Unique request identifier for support

cachedboolean required

Whether the response was served from cache

idempotent_replayboolean

True only when this response is an idempotency replay

Example response

{
  "success": true,
  "platform": "linkedin",
  "endpoint": "/v1/linkedin/company/people",
  "credits_used": 1,
  "credits_remaining": 4999,
  "request_id": "req-abc123",
  "idempotent_replay": true,
  "meta": {
    "hint": {
      "code": "search_multi",
      "message": "You searched \"matcha\" on 3 platforms one call at a time; /v1/search/multi returns each platform's own search rows in one call at the same price per platform, and a platform with no rows is not charged.",
      "method": "GET",
      "path": "/v1/search/multi?query=matcha&platforms=instagram,tiktok,youtube"
    }
  },
  "pagination": {
    "next_cursor": "sc.eyJ2IjoyLCJjIjoiMiIsInAiOiJwYWdlIn0",
    "has_more": true,
    "page_size": 30,
    "stopped_at": "known_id"
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.