# Connections and Invitations

Coming soon – the network signal reports accepted invitations, new connections and incoming connection requests on a LinkedIn account.

> 🚧 **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`](/docs/monitoring-network) 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`](/docs/action-st-check-connection-status) 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`](/docs/action-st-retrieve-connections), [`st.retrieveInvitations`](/docs/action-st-retrieve-invitations) and [`st.retrievePendingRequests`](/docs/action-st-retrieve-pending-requests).

## 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](/docs/data-conventions#linkedin-urns) 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](/docs/signal-events#polling).

## Accepted invitations: a common flow

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

1. Create the `network` signal once per account, **before** you start sending invitations – an acceptance that happens before the baseline is not reported.
2. Send invitations with [`st.sendConnectionRequest`](/docs/action-st-send-connection-request) as usual.
3. React to `connectionAccepted` events – for example, send the first message with [`st.sendMessage`](/docs/action-st-send-message).

An invitation that was not accepted produces no event. To find invitations that have waited too long, read them with [`st.retrievePendingRequests`](/docs/action-st-retrieve-pending-requests) and withdraw them with [`st.withdrawConnectionRequest`](/docs/action-st-withdraw-connection-request).

## Until signals launch: st.syncNetwork

Until signals launch, the same events come from [network monitoring](/docs/monitoring-network), enabled with the [`st.syncNetwork`](/docs/action-st-sync-network) 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`](/docs/monitoring-network) 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.