Signals Overview

🚧 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.

A workflow does something now: open a profile, search, send a message. A signal tells you when something happens: a person publishes a post, someone comments under your post, a new person views your profile, an invitation is accepted.

You create a signal once. From then on, Linked API checks its target in the background, inside the account's working hours and within its limits, and records an event every time something new appears. You read the events by polling one endpoint or receive them as webhook events. No cron job on your side, and no re-reading the same profile every day to see whether anything changed.

💡 New messages are not a signal type: they are covered by inbox monitoring, which also keeps the conversations themselves, so you can read a whole thread and not just learn that it changed.

How a signal works

1. You create it with POST /signals: a type and a target, such as a person's URL or a keyword. See Managing signals.
2. The first check is a silent baseline. It records what is already there – existing posts, comments, connections, viewers – and emits nothing. Only what appears after it becomes an event.
3. Linked API checks the target on a schedule – see How often a signal is checked. A check compares what LinkedIn shows with what the signal has already seen.
4. Every new item becomes an event. Poll them with /signals/poll or receive them as signal.* webhook events. Events are kept for 90 days.

A check reads LinkedIn through the same cloud browser and the same actions you can run yourself – a signal on a person's posts reads what st.retrievePersonPosts would return. A signal saves you the scheduling and the comparing, not the reading.

How often a signal is checked

The times are spread inside the account's working hours, so checks do not land at the same minute every day.

Signals and your own work

Signals share the account with your workflows, and they are designed to stay out of their way:

• Your workflows go first. An account runs one thing at a time. A check starts only when no workflow of yours is waiting, so it never jumps ahead of your requests. A workflow you send while a check is running waits for that check to finish, then runs in workflow queue order. An account that is busy all day gets fewer checks.
• Checks stay inside working hours, under every off-hours policy – the same as inbox and network synchronisation.
• Checks spend the same limits as your actions. LinkedIn sees one account, so a profile view by a signal counts like any other. To keep room for your own work, a signal stops spending a limit once less than a fifth of it remains for the current period. The skipped check moves to the next period, and your workflows keep that last fifth.
• Checks pause with the account. While the account needs reconnection or is frozen, nothing is checked. Checks resume on their own once the account is active again.

With default limits, 20 personPosts signals use about 40 of the account's 80 daily profile views, and 2 postSearch signals use about 120 of its 300 monthly searches. Plan the number of signals around what your own workflows need.

Limits on signals

• Up to 50 active signals per account. Paused signals do not count.
• One network and one profileViewers signal per account – they watch the account itself and take no target.
• Creating a signal that already exists – the same type and target on the same account – returns the existing signal instead of a second one.

Signals in SDKs, CLI and AI agents

The same signals are available in every way you reach Linked API:

For an AI agent, a signal is the missing piece of "keep an eye on it": an agent cannot receive webhooks or wake itself up on a schedule, but it can ask what is new since the last time – and the answer is already collected.