Skip to main content

Account API Documentation

Account API lets you manage LinkedIn accounts programmatically through an API interface. Here, you’ll find an explanation of the API design philosophy and implementation details.

RPC-style

Instead of the commonly used REST approach, Account API follows an RPC-style design:

  • All requests are POST requests structured as action calls, such as conversations.sendMessage, combining a domain and a function name.
  • Each function accepts a specific body JSON, depending on the API endpoint, which is treated as the function's parameter.

This approach provides greater flexibility in defining actions, as the API is action-oriented rather than resource-oriented.

Request timing

Since Account API fully emulates actions of a real LinkedIn user, requests are not executed instantly. For example, simple actions like liking a post might take around 20 seconds, while more complex operations, such as retrieving detailed company information including a list of its employees, can take several minutes.

It's important to consider this behavior when integrating the API into your services. To support flexible integration even with long-running requests, we offer 3 different result handling options. You can learn more about them on the result handling page.

Sequential execution

Account API executes requests sequentially to emulate the actions of a real LinkedIn user. While you can send multiple requests in quick succession, they will not be executed in parallel. Each request is accepted immediately, but its execution will not start until the previous request is completed.

For example, if you send a request like connections.checkStatus and immediately send another request to conversations.sendMessage, the second request’s execution will begin only after the first request is completed.

This approach ensures alignment with realistic user behavior on LinkedIn, as it mirrors how a real user would interact with the platform.

Array requests

Most endpoints in Account API are designed to support array requests. For instance, connections.checkStatus accepts an array of LinkedIn profile URLs to check connection status, and conversations.sendMessage allows sending messages to multiple recipients in a single API call.

Whenever possible, prefer array requests with multiple elements instead of multiple requests with a single element. This approach significantly reduces execution time.

For example, checking connection status for one person using connections.checkStatus takes around 20 seconds. Making 10 separate requests for 10 different people would take approximately 200 seconds in total. However, combining all 10 profiles into a single array request reduces the total execution time to about 50 seconds.

Limits responsibility

Account API does not impose any restrictions to enforce LinkedIn limits, so it is up to you to manage them. LinkedIn limits vary depending on your account's age, social selling index, subscription (e.g., Sales Navigator), and other factors.

You are responsible for following your account's specific limits to avoid potential restrictions.

To help monitor your activity, Account API provides endpoints for retrieving usage statistics (e.g., messages sent, connection requests made) and checking SSI. Also check out our detailed guide on understanding LinkedIn limits.

URL normalization

Account API normalizes all LinkedIn URLs in responses, regardless of the format provided in the request body. Normalized URLs consistently follow these rules:

  • Use https protocol.
  • Include www subdomain.
  • Exclude trailing slash (/).

For example, if a request body includes a URL like http://linkedin.com/in/person1/, the response will return it as https://www.linkedin.com/in/person1. Consider this behavior when implementing URL comparisons or storage in your integration.

Handling missing values

When certain data is unavailable on LinkedIn, some fields in the API response may return as null or empty array ([]). Missing fields are always explicitly included in the response rather than being omitted.