Connections and Invitations

🚧 Coming soon. Signals are not available yet. This page describes how they will work at launch – the /signals endpoints, signal.* events and the SDK, CLI and MCP signal commands do not work today. Network monitoring – /network/poll and the network.* webhook events – works today.

The network signal watches the account's own connections and invitations. Use it instead of re-checking each person with st.checkConnectionStatus or re-reading the connection list to see what changed.

Events

Event `type`	Webhook event	What happened
`connectionAccepted`	`signal.connectionAccepted`	Someone accepted an invitation you sent.
`connectionAdded`	`signal.connectionAdded`	A new connection that is not from an invitation you sent – for example, you accepted someone's invitation, or the connection was made outside the API.
`connectionRequestReceived`	`signal.connectionRequestReceived`	Someone sent you an invitation.

💡 Together, connectionAccepted and connectionAdded cover every new 1st-degree connection. If you only care that the network grew, handle both.

Creating

The signal watches the account itself and takes no target. An account has at most one.

json

{
  "type": "network"
}

Checked	Each check spends
every hour	nothing from account limits

The baseline is the account's connections and pending invitations at the moment of the first check. They are never reported as events. To get the current state – the full list, or what happened before the signal existed – use st.retrieveConnections, st.retrieveInvitations and st.retrievePendingRequests.

Event fields

json

{
  "id": "f4d92946-8821-6da6-ff4c-c36f0671292a",
  "signalId": "0e6f1a2b-7c8d-4e9f-a0b1-c2d3e4f5a6b7",
  "signalType": "network",
  "label": null,
  "type": "connectionAccepted",
  "detectedAt": "2026-10-12T11:35:00Z",
  "personUrn": "urn:li:member:987654321",
  "personUrl": "https://www.linkedin.com/in/person2"
}

personUrn – URN of the other person, or null if LinkedIn did not expose it.
personUrl – LinkedIn URL of the other person.

The common fields – id, signalId, signalType, label, type, detectedAt – are described in Receiving events.

Accepted invitations: a common flow

After outreach, the usual question is who accepted. With the network signal there is nothing to re-check:

Create the network signal once per account, before you start sending invitations – an acceptance that happens before the baseline is not reported.
Send invitations with st.sendConnectionRequest as usual.
React to connectionAccepted events – for example, send the first message with st.sendMessage.

An invitation that was not accepted produces no event. To find invitations that have waited too long, read them with st.retrievePendingRequests and withdraw them with st.withdrawConnectionRequest.

The network signal and network monitoring

Until signals launch, the same changes come from network monitoring, enabled with the st.syncNetwork action. After launch, the two stay separate:

network monitoring keeps working as it does today: its events come from /network/poll and as network.* webhook events;
the network signal is created with POST /signals, and its events come from /signals/poll and as signal.* webhook events, like those of every other signal.

On an account with both, each change is reported by each of them: an accepted invitation arrives as network.connectionAccepted and as signal.connectionAccepted. If you move to the signal, handle only one of them – for example, leave network.* out of your webhook's event selection.

New code should use the network signal, so all signals of the account are managed and read in one place.

PreviousReceiving Events NextPosts by Person or Company