Monitoring network
Network monitoring lets you track changes to an account's connection graph in the background, instead of repeatedly retrieving connections and pending requests and diffing them yourself. It involves 2 key steps:
In the Node SDK this is two calls: linkedapi.syncNetwork once per account, then linkedapi.pollNetwork() to read the events.
In the Python SDK this is two calls: linkedapi.sync_network once per account, then linkedapi.poll_network() to read the events.
In the CLI this is two commands: linkedin network sync once per account, then linkedin network events to read the events.
- Enabling. Enable network sync once per account. From that point on, Linked API watches the account's network in the background and captures connection events.
- Polling. After network sync is enabled, poll a single endpoint to retrieve captured events and receive new ones — without retrieving the whole connection list each time.
💡 Monitoring does not import history. Only changes that happen after you enable it are captured — your existing connections and pending invitations are used as a silent baseline and never emitted. When you need the state as it is right now (a full list, a one-off audit, backfilling before monitoring was on), reach for
st.retrieveConnectionsandst.retrieveInvitationsinstead.
Enabling
Execute a workflow with the st.syncNetwork action. You only need to do this once per account.
{
"actionType": "st.syncNetwork"
}Completion:
{
"actionType": "st.syncNetwork",
"success": true
}Event types
Network monitoring emits three kinds of events:
connectionRequestReceived– someone sent you a connection request. A new incoming pending invitation was observed.connectionAccepted– a new connection that matches a request you sent. The other person accepted your outgoing invitation.connectionAdded– a new connection that is not attributable to a request you sent. For example, you accepted someone else's incoming request, or the connection was formed outside the API.
💡 Together,
connectionAcceptedandconnectionAddedcover every new first-degree connection:connectionAcceptedis the subset you initiated,connectionAddedis everything else. If you only care that the network grew, handle both.
Polling
Unlike enabling, you don't execute workflows to poll the network. Instead, send a POST request to the following endpoint:
POST https://api.linkedapi.io/network/pollThe request body is a single object. All fields are optional:
Unlike enabling, polling is a direct request, not a workflow. All parameters are optional:
{
"since": "2023-01-01T00:00:00Z",
"type": "connectionAccepted"
}In the Node SDK this is the pollNetwork method; it takes the fields below and returns the result object below as data, so the events are in data.events.
In the Python SDK this is the poll_network method; it takes the fields below as a NetworkPollRequest. It returns the events themselves: result.data is a list of NetworkEvent objects with the fields below in snake_case, so iterate result.data directly.
In the CLI this is linkedin network events:
linkedin network events [flags]| Flag | Type | Description |
|---|---|---|
--since | string | Only retrieve events after this ISO timestamp |
--type | string | Filter by event type: connectionRequestReceived, connectionAccepted, or connectionAdded (default: all) |
Requires network monitoring to be enabled once with
network sync. Events are retained for 90 days.
since(optional) – timestamp indicating the starting point for retrieving events. If not provided, all captured events are returned.type(optional) – filter by a single event type. If omitted, all event types are returned:connectionRequestReceivedconnectionAcceptedconnectionAdded
If your request is correct, you will receive the following response:
Result – data is the result object below:
Result – result.data is the events list below, as NetworkEvent objects with snake_case fields:
Output – with --json or into a pipe, the CLI prints this result as data, so the events are in data.events:
{
"success": true,
"result": {
"events": [
{
"id": "f4d92946-8821-6da6-ff4c-c36f0671292a",
"type": "connectionAccepted",
"personUrn": "urn:li:member:123456789",
"personUrl": "https://www.linkedin.com/in/person1",
"detectedAt": "2023-01-02T10:35:00Z"
},
{
"id": "2a1b7f25-daba-5e20-70e9-c6427bb4f660",
"type": "connectionRequestReceived",
"personUrn": null,
"personUrl": "https://www.linkedin.com/in/person2",
"detectedAt": "2023-01-02T09:12:00Z"
}
]
}
}events– array of connection events, ordered newest first.id– unique identifier for the event.type– one ofconnectionRequestReceived,connectionAccepted, orconnectionAdded.personUrn– URN of the other person, ornullif LinkedIn did not expose an identifier on the row that produced the event. Events recorded before URN support was added always returnnull.personUrl– LinkedIn URL of the other person.detectedAt– timestamp when Linked API observed the event.
Recommended flow for integrations:
- Leave
sinceempty on the first request to retrieve everything captured so far. - For subsequent requests, pass the timestamp of the most recent event you received as
sinceto fetch only newer events. - Continue polling with an advancing
since. Whenever new events arrive, updatesinceto the latestdetectedAt.
Events are retained for 90 days. Poll (or receive webhooks) often enough to consume them within that window — older events are pruned and will no longer be returned.
💡 For push-based delivery instead of polling, subscribe to the network Webhook Events. They fire for accounts with network monitoring enabled and carry the same event fields.
This page provides examples of workflows and their completions. For detailed documentation on constraints, parameters, and possible results of specific actions, always refer to the corresponding action documentation pages.