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`	`network.connectionAccepted`	Someone accepted an invitation you sent.
`connectionAdded`	`network.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`	`network.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.

Until signals launch: st.syncNetwork

Until signals launch, the same events come from network monitoring, enabled with the st.syncNetwork action. At launch, both ways will turn on the same thing:

an account that ran st.syncNetwork will already have a network signal, and GET /signals will list it;
st.syncNetwork on an account with a network signal will change nothing;
/network/poll and the network.* webhook events will keep working and carry the same events.

Once signals launch, new code should use POST /signals and /signals/poll, so all signals of the account are managed and read in one place.

PreviousReceiving Events NextPosts by Person or Company