Webhook Event Types

Every event arrives in the same envelope. This page lists the event types by area and explains how to choose which of them your webhook receives.

Workflow events

data carries workflowId, accountId, and status. All events for one run share the same workflowId, so you can correlate them.

• workflow.created – your request was accepted and queued. status is pending.
• workflow.started – the workflow actually started running. status is running.
• workflow.completed – the workflow reached a terminal state. status is completed or failed.

data.result is included only on workflow.completed, and only in fat payload mode. Cancelled workflows do not emit a webhook.

Account events

data carries accountId and status, emitted when a connected LinkedIn account changes status.

• account.reconnectionRequired – the account needs the user to reconnect. status is reconnection_required.
• account.active – the account (re)connected and is operational. status is active.
• account.frozen – the account was frozen, for example due to an unpaid subscription. status is frozen.
• account.deleted – the account was deleted. status is deleted.

Inbox events

The inbox.* namespace covers messages observed in a connected account's inbox, as opposed to the state of your own Linked API entities. These events fire for accounts that have inbox monitoring enabled via st.syncInbox / nv.syncInbox, one event per inbox message. History loaded with st.syncConversation / nv.syncConversation does not produce events.

• inbox.messageReceived – an incoming message was observed in the inbox.
• inbox.messageSent – an outgoing message from the account was observed. This covers messages sent through the LinkedIn UI and messages sent through the Linked API, so an API-sent message emits inbox.messageSent in addition to its workflow.completed.

data carries the message with the following fields:

• accountId – the connected LinkedIn account the message belongs to.
• type – inbox type the message belongs to (st or nv).
• threadId – identifier of the conversation thread. Pass it to st.sendMessage / nv.sendMessage to reply.
• personUrn – URN of the other participant, or null if LinkedIn does not expose it.
• personHashedUrl – hashed LinkedIn URL of the other participant. This is the form the inbox exposes; every action that takes a person URL accepts it.
• personPublicUrl – public LinkedIn URL of the other participant, or null if it has not been resolved. It can be null on any message, including the first one in a thread, so never treat it as guaranteed. See inbox polling for how it is resolved.
• personUrl – deprecated, replaced by personHashedUrl, which carries the same value. Still sent so existing subscribers keep working; do not use it in new code.
• messageId – unique identifier of the message, matching the id returned by inbox polling.
• sender – us for inbox.messageSent, them for inbox.messageReceived.
• text – message text.
• time – ISO 8601 timestamp of the message.

Because inbox.messageSent also fires for outbound messages your own automations send, filter by data.sender and data.type rather than assuming every event is a fresh inbound reply.

Network events

The network.* namespace covers changes to a connected account's connection graph. These events fire for accounts that have network monitoring enabled via st.syncNetwork, one event per connection change.

• network.connectionRequestReceived – someone sent the account a connection request. A new incoming pending invitation was observed.
• network.connectionAccepted – a new connection that matches a request the account sent. The other person accepted an outgoing invitation.
• network.connectionAdded – a new connection that is not attributable to a request the account sent, for example an incoming request the account accepted, or a connection formed outside the API.

data carries the connection event with the following fields:

• accountId – the connected LinkedIn account the event belongs to.
• personUrn – URN of the other person, or null if LinkedIn did not expose an identifier on the row that produced the event.
• personUrl – LinkedIn URL of the other person.
• detectedAt – ISO 8601 timestamp of when Linked API observed the event, matching the detectedAt returned by network polling.

Signal events

🚧 Coming soon. Signals are not available yet. These events will be delivered once they launch.

The signal.* namespace covers what your signals detect, one event per new item. data carries the event exactly as /signals/poll returns it, plus accountId.

• signal.postPublished – a watched person or company published a post. See Posts by person or company.
• signal.postFound – a new post matched a keyword signal. See Posts by keyword.
• signal.commentAdded – a new comment under a watched post. See Comments and reactions.
• signal.reactionAdded – a new reaction on a watched post. See Comments and reactions.
• signal.profileViewed – a new identified viewer of the account's profile. See Profile viewers.

The network signal keeps the network.* events above.

Event selection

By default a webhook receives every event on this page. You can narrow it to the events you handle. The choice is optional and per webhook, and a webhook that never makes one keeps receiving every event, so existing webhooks are unchanged.

In the dashboard, open Advanced → Events on your endpoint, or in the dialog that creates it, and switch off All events to choose. The endpoint's Events row shows the current selection. Programmatically, pass events to webhook.set, change it later with webhook.setEvents, and list the types you can choose with webhook.eventTypes.

A selection is either null, meaning every event, or a list whose entries are each:

• an exact event type, such as workflow.completed;
• a namespace wildcard <namespace>.*, such as inbox.*. The namespace is the part before the first .: workflow, account, inbox, network or, once signals launch, signal.

A wildcard follows the family; an exact type pins it. inbox.* matches every inbox event, including event types added later. inbox.messageReceived matches only itself and never widens. In the dashboard, choosing a whole group stores its wildcard, while ticking each of its types one by one stores those exact types.

A selection is checked when you save it. An unknown type or namespace, webhook.test, webhook.*, a bare *, any other pattern, or an empty list is rejected with invalidRequestPayload naming the entry, so a typo never becomes a webhook that silently receives nothing. A selection holds up to 50 entries of up to 64 characters each. It is stored de-duplicated and sorted, and reading the webhook returns it as events.

Delivered whatever you select:

• webhook.test, so webhook.sendTest works on any webhook;
• a replayed delivery, even of a type you have deselected since.

An event you do not select is never recorded. Filtering happens when the event is produced, so a deselected event creates no delivery at all. It does not appear in recent deliveries, cannot be replayed, and does not come back if you select its type later.

A change applies from the moment you save it. Events produced after that follow the new selection. Deliveries that were already queued, pending or being retried, are still delivered.