Blog/Developer Tools/

LinkedIn Public Data API: Profiles, Companies & Posts | SandBase

Read public LinkedIn profiles, company pages, posts, and jobs with one REST API. No LinkedIn OAuth, no SDK — one SandBase key, built for agent workflows.

By Sophie Lin
Dark cinematic render of LinkedIn profile and company data flowing through one API conduit into an agent core

Pulling public LinkedIn data into an agent usually means fighting LinkedIn’s own barriers first: login walls, OAuth scopes you cannot get approved for, and brittle scrapers that break on every layout change. The data on a public company page or profile is visible in a browser, but wiring it into a B2B enrichment, recruiting, or research workflow reliably is a project of its own.

The SandBase LinkedIn public data API removes that setup tax. It reads public LinkedIn profiles, company pages, posts, and job listings through plain REST endpoints — one SandBase API key, no LinkedIn OAuth flow and no SDK. The endpoint reference only guarantees the envelope (id, status, model, and outputs[0].data); the business fields shown below are an illustrative structure, not a guaranteed schema, so confirm the exact fields against a live response.

This is not LinkedIn’s official Marketing or Talent Solutions API. Use LinkedIn’s official APIs when you need authorized member actions, posting on behalf of a member, or ads management. Use SandBase when your workflow needs public, read-only enrichment, monitoring, or research data. Ready to try it? Get a SandBase API key and browse the LinkedIn endpoints.

Key takeaway

  • One API reads public LinkedIn profiles, company pages, posts, comments, and job detail.
  • The Model API endpoints in this guide are called with POST /v1/api/linkedin/<path> — pass only that endpoint’s params, no SDK, one SANDBASE_API_KEY.
  • Most web-v2 endpoints key off a LinkedIn url (profile, company, post, or job URL); read each endpoint’s schema.
  • It returns public, read-only data only. There is no posting, no LinkedIn OAuth login, and no access to private or connection-gated data; authenticate with a SandBase API key.

Which LinkedIn API do you need?

Your needChooseWhy
Post as a member, run ads, or act on an authorized accountLinkedIn official APIsMarketing and Talent Solutions APIs for authorized member and ad actions.
Read public profiles, company pages, posts, or job listingsSandBase LinkedIn public-data APIPlain REST, one SandBase key, structured JSON for read-only workflows.
Access private/connection-only data, messages, or member-authorized fieldsNeither public workflowThose data types are out of scope for this public-data guide.

What you can get from the LinkedIn API

The web-v2 surface handles single-resource reads by URL. Grouped by job:

  • Profiles — public member profiles by URL (about, city, activity, links).
  • Companies — public company pages by URL (industry, size, followers, headquarters, specialties, employees).
  • Posts & comments — a profile’s or company’s posts, single post detail, and post comments.
  • Jobs — job search and job detail (title, hiring team, skills).

For higher-volume research, check the live LinkedIn API listing for the current set of endpoints. Not every listed capability is enabled for direct calls yet, so treat each endpoint’s live API reference as the source of truth before you build.

SandBase LinkedIn API page: description, capability tags, and the LinkedIn Endpoints list The LinkedIn API page on SandBase — a tagged overview and the endpoint list, each with its path.

What LinkedIn provides vs. what SandBase adds

Public data comes from LinkedIn. SandBase does not own or operate LinkedIn; it provides a uniform API layer for eligible public-data workflows. Each capability becomes one stable endpoint, auth collapses to a single key, and responses come back as predictable JSON — so an agent can chain “resolve a company page → read its size and industry → pull its recent posts” along one convention instead of maintaining a scraper per surface.

Quick start: your first call

SandBase exposes more than one API surface. The catalog may show GET paths under /apis/v1/...; this guide uses the vendor-qualified Model API path on each endpoint’s API reference. Do not swap the HTTP method or URL — follow the reference for the endpoint you choose.

Read a public company page by its LinkedIn URL:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/linkedin/web-v2/company-profile",
    headers={
        "Authorization": f"Bearer {os.environ['SANDBASE_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={"url": "https://www.linkedin.com/company/microsoft/"},
)
resp.raise_for_status()
body = resp.json()
if body.get("status") != "completed":
    error = body.get("error", {})
    raise RuntimeError(error.get("message", "LinkedIn request did not complete"))

company = body["outputs"][0]["data"]
# Business fields are an illustrative shape, not a guaranteed schema — read defensively.
print(company.get("name"), company.get("company_size"), company.get("followers"))
curl -X POST https://api.sandbase.ai/v1/api/linkedin/web-v2/company-profile \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.linkedin.com/company/microsoft/"}'

Every response uses the same envelope: an id, a status, the model name, and an outputs array whose single item carries the payload under data. Branch on status before reading outputs[0].data, and check each endpoint’s reference for its run mode. The block below is an illustrative response shape for company-profile — the business fields are an example structure, not a guaranteed schema, so treat the values as examples and confirm the exact fields against a live response, since payloads vary and change over time:

{
  "id": "009e56c4-8759-44b3-938b-763043779b79",
  "status": "completed",
  "model": "linkedin/web-v2/company-profile",
  "outputs": [
    {
      "data": {
        "name": "Microsoft",
        "company_id": "1035",
        "company_size": "10,001+ employees",
        "followers": 29171590,
        "headquarters": "Redmond, Washington",
        "website": "https://news.microsoft.com/"
      }
    }
  ]
}

A failed or timeout run carries error and never outputs, so branch on status before reading outputs[0].data. Response shapes differ by endpoint — inspect one real response and map the exact path per endpoint.

SandBase API reference for a LinkedIn endpoint, showing the vendor-qualified URL, the url parameter, and the response schema The endpoint API reference is the source of truth for each parameter name and response path.

Capability map

Capability clusterRepresentative endpointTypical use
Company profilelinkedin/web-v2/company-profileFirmographic enrichment by company URL
Member profilelinkedin/web-v2/user-profilePublic profile enrichment by URL
Postslinkedin/web-v2/company-posts, linkedin/web-v2/user-postsContent monitoring, thought-leadership tracking
Post commentslinkedin/web-v2/post-commentsEngagement and sentiment analysis
Jobslinkedin/web-v2/job-detailJob-market and hiring research
Post commentslinkedin/web-v2/post-commentsEngagement and sentiment inputs

Paging differs by endpoint — several web-v2 list endpoints use a pagination_token and start, while post-comments uses a page. Read each endpoint’s schema.

SandBase LinkedIn Endpoints list showing profile, company, posts, and jobs endpoints with their paths A slice of the LinkedIn endpoint list on the web-v2 surface.

Common use cases

LinkedIn company API for firmographic enrichment

Resolve a company URL with linkedin/web-v2/company-profile, then read industry, company_size, followers, and headquarters to enrich a CRM or lead record. Input: a company LinkedIn URL. Output: a structured firmographic record. Endpoint: company-profile.

LinkedIn profile API for people research

Read a public member profile with linkedin/web-v2/user-profile for about, city, and activity signals. Input: a profile URL. Output: a structured profile record. Endpoint: user-profile.

LinkedIn posts API for thought-leadership monitoring

Poll a company’s or member’s recent posts on a schedule and track engagement over time. Input: a company or profile URL. Output: a list of posts with engagement. Endpoints: company-posts and user-posts.

Chaining calls in an agent workflow

Because every endpoint shares the same auth and the same response envelope, an agent can walk from one public resource to the next without special-casing each surface. A common B2B pattern looks like this:

  1. Resolve the company. Call linkedin/web-v2/company-profile with the company URL and read company_id, industry, company_size, followers, and headquarters — the firmographic core for a CRM record.
  2. Pull recent activity. Call linkedin/web-v2/company-posts with the same company URL to see what the organization is publishing, then page with the token the response returns.
  3. Enrich a decision-maker. Call linkedin/web-v2/user-profile with a public member URL to attach role and location context to the account.

Each step is one POST with one url parameter, and each returns the same { id, status, model, outputs } shape. Your agent branches on status once and reuses the same JSON-reading code across every step — that uniformity is the point. When you need higher volume than single-URL reads, check the live LinkedIn API listing for the current set of endpoints and confirm parameters against each reference before wiring it in.

A practical tip: cache the company_id you get back from company-profile. It is a stable identifier you can store against your own records, so re-enrichment runs later only need to re-read the fields that change (like followers) rather than re-resolving the entity from scratch.

Limitations and boundaries

  • Public, read-only data only. No posting, messaging, connection actions, or connection-gated fields.
  • Rate and volume. Treat responses as best-effort reads; as a client-side resilience measure, retry with backoff on transient errors such as HTTP 429.
  • Parameters and shapes follow the upstream surface. Most web-v2 reads take a url; paging varies (pagination_token/start vs page). Inspect a real response and read the schema first.
  • Not every listed endpoint is callable yet. Verify against the live API reference before building on a specific endpoint.
  • This is not an official LinkedIn partnership. SandBase provides uniform access to public data; respect LinkedIn’s terms and applicable privacy rules for your use case.

FAQ

Do I need a LinkedIn developer app or OAuth? No. You authenticate to SandBase with your SANDBASE_API_KEY. You do not register a LinkedIn app or manage OAuth for these read endpoints.

What identifies a company or profile? Most web-v2 endpoints take the public LinkedIn url (e.g. a /company/<name>/ or /in/<handle>/ URL). Post comments take a urn.

How does pagination work? It depends on the endpoint. Several web-v2 list endpoints use pagination_token plus start; post-comments uses page. Read each endpoint’s schema.

Can I read private or connection-only data? No. The API returns public data only. Private fields, messages, and connection-gated data are out of scope.

Can I search for people or companies at higher volume? Check the live LinkedIn API listing for the current set of endpoints and their supported parameters, and confirm availability against each endpoint’s reference before building on it.

Start with one company request

Create a SandBase API key, run company-profile against a public company URL, and inspect the returned schema before you expand to profiles, posts, or jobs. When you are ready: