How to Automate LinkedIn Messages (2026): What's Possible, What's Safe, and How to Do It in Code

If you send the same LinkedIn connection requests and follow-up messages by hand every week, you have already hit the ceiling: it does not scale, and copy-pasting into the message box is exactly the work a computer should do. This guide covers what you can automate on LinkedIn, the safe ways to do it, and – for teams who want it wired into their own product or CRM – the exact connect-to-reply flow in code.

The short version. Standard LinkedIn messaging has no native way to schedule or sequence outbound DMs (LinkedIn documents scheduled outreach only for its paid recruiting tools – Recruiter and Recruiter Lite can schedule initial InMail, and Recruiter alone can schedule one automated follow-up; Premium's away message is just an auto-reply), so automating everyday outreach means a tool or an API acting on your own account. The real automation is a branching loop: if you are already connected, send a message; if not, either send a connection request → wait until it is accepted → message, or use Sales Navigator InMail to reach a non-connection directly. Then read the reply, or monitor your whole inbox for incoming messages at scale. Keep it on your own account, at a human pace, within LinkedIn's limits.

Can you automate LinkedIn messages?

Yes – but for regular direct messages, not with a native LinkedIn button. LinkedIn's own Message content automation page is about inbound processing – how it renders and suggests replies to messages you receive – not about scheduling messages you send.

The one place LinkedIn documents scheduled outbound is its paid recruiting product: per LinkedIn's help center, you can schedule initial outreach InMail in Recruiter and Recruiter Lite, and schedule one automated follow-up InMail in Recruiter only. Everyday Messaging has no equivalent, and the Premium away message is an automatic reply shown to people who message you – not a way to send scheduled outreach.

So for standard outreach, "automating LinkedIn messages" means a tool or an API that performs the clicks and keystrokes on your own account. The rest of this guide is how to do that well.

The three ways to automate LinkedIn messages

There are three approaches, and the right one depends on how much control you need and whether you write code.

The first two are covered well elsewhere (see our roundup of LinkedIn automation tools for the "which tool" question). This guide focuses on the third, because it is the one no listicle actually shows you: the real flow, in code, on your own account.

What you can automate: messages, InMail, and connection notes

Before the code, get the routing right – who you can message depends on your relationship to them.

Two honest boundaries that pages blurring "reach anyone instantly" skip: a standard message only works once someone is a 1st-degree connection, and reaching a non-connection means either connecting first or spending a Sales Navigator InMail. There is no button that DMs a stranger for free.

How to automate the full flow (in code)

Here is the branching loop with Linked API, the LinkedIn automation API that runs these actions on your own account. Install the SDK (npm install -S @linkedapi/node or pip install linkedapi) and initialise the client with your tokens.

The core decision is the acceptance gate – the step generic messaging relays skip. You check where you stand, and only message a first-degree connection; if you are not connected, you send a request and message after it is accepted. Handle one edge as you go: some people require a verified email to accept a request, which sendConnectionRequest reports as emailRequired. Email is an optional input for that case only – Linked API never returns email as data.

import LinkedApi from '@linkedapi/node';

const linkedapi = new LinkedApi({
  linkedApiToken: process.env.LINKED_API_TOKEN,
  identificationToken: process.env.IDENTIFICATION_TOKEN,
});

const NOTE = 'Hi! I work on LinkedIn tooling and would love to connect.';

async function reach(personUrl: string, text: string, knownEmail?: string): Promise<void> {
  // 1. Where do we stand? -> connected | pending | notConnected
  const check = await linkedapi.checkConnectionStatus.execute({ personUrl });
  const { data } = await linkedapi.checkConnectionStatus.result(check.workflowId);

  // 2. Already connected -> message them directly.
  if (data?.connectionStatus === 'connected') {
    const sent = await linkedapi.sendMessage.execute({ personUrl, text });
    await linkedapi.sendMessage.result(sent.workflowId);
    return;
  }

  // 3. Not connected -> send a request; message only once it is accepted.
  if (data?.connectionStatus === 'notConnected') {
    const req = await linkedapi.sendConnectionRequest.execute({ personUrl, note: NOTE });
    const { errors } = await linkedapi.sendConnectionRequest.result(req.workflowId);

    // Edge: this person needs a verified email. Retry with one if you have it.
    if (errors?.some((e) => e.type === 'emailRequired') && knownEmail) {
      const retry = await linkedapi.sendConnectionRequest.execute({
        personUrl, note: NOTE, email: knownEmail,
      });
      await linkedapi.sendConnectionRequest.result(retry.workflowId);
    }
    // Re-run checkConnectionStatus on a schedule (cron or webhook);
    // when it returns 'connected', call sendMessage. Do not busy-wait.
  }
}

from linkedapi import (
    LinkedApi,
    LinkedApiConfig,
    CheckConnectionStatusParams,
    SendMessageParams,
    SendConnectionRequestParams,
    NvSendMessageParams,
    SyncConversationParams,
    NvSyncConversationParams,
    ConversationPollRequest,
    InboxPollRequest,
)

linkedapi = LinkedApi(
    LinkedApiConfig(
        linked_api_token="your-linked-api-token",
        identification_token="your-identification-token",
    )
)

NOTE = "Hi! I work on LinkedIn tooling and would love to connect."

def reach(person_url: str, text: str, known_email: str | None = None) -> None:
    # 1. Where do we stand? -> connected | pending | notConnected
    check = linkedapi.check_connection_status.execute(
        CheckConnectionStatusParams(person_url=person_url)
    )
    data = linkedapi.check_connection_status.result(check.workflow_id).data

    # 2. Already connected -> message them directly.
    if data and data.connection_status == "connected":
        sent = linkedapi.send_message.execute(
            SendMessageParams(person_url=person_url, text=text)
        )
        linkedapi.send_message.result(sent.workflow_id)
        return

    # 3. Not connected -> send a request; message only once it is accepted.
    if data and data.connection_status == "notConnected":
        req = linkedapi.send_connection_request.execute(
            SendConnectionRequestParams(person_url=person_url, note=NOTE)
        )
        errors = linkedapi.send_connection_request.result(req.workflow_id).errors

        # Edge: this person needs a verified email. Retry with one if you have it.
        if known_email and any(e.type == "emailRequired" for e in (errors or [])):
            retry = linkedapi.send_connection_request.execute(
                SendConnectionRequestParams(
                    person_url=person_url, note=NOTE, email=known_email
                )
            )
            linkedapi.send_connection_request.result(retry.workflow_id)
        # Re-run check_connection_status on a schedule (cron or webhook);
        # when it returns "connected", call send_message. Do not busy-wait.

To reach someone you are not connected to without waiting, send a Sales Navigator InMail instead. This route has no acceptance gate, but it needs a Sales Navigator seat and a subject line.

const inmail = await linkedapi.nvSendMessage.execute({
  personUrl,
  subject: 'Quick question about your team',
  text: 'Hi Dana, saw your team is hiring SDRs. Mind if I share how we help?',
});
await linkedapi.nvSendMessage.result(inmail.workflowId);

inmail = linkedapi.nv_send_message.execute(
    NvSendMessageParams(
        person_url=person_url,
        subject="Quick question about your team",
        text="Hi Dana, saw your team is hiring SDRs. Mind if I share how we help?",
    )
)
linkedapi.nv_send_message.result(inmail.workflow_id)

Finally, read the reply. syncConversation turns on message capture once, then pollConversations returns the messages, each tagged with a sender of us or them, so you can detect a real response. A standard message and a Sales Navigator InMail live in different threads, so match the sync method and the type to the route: syncConversation with type: 'st' for a connection, nvSyncConversation with type: 'nv' for an InMail.

// Standard reply (connection route): sync once, then poll the 'st' thread.
const s1 = await linkedapi.syncConversation.execute({ personUrl });
await linkedapi.syncConversation.result(s1.workflowId);
const { data } = await linkedapi.pollConversations([{ personUrl, type: 'st' }]);
const theirReplies = data?.[0]?.messages.filter((m) => m.sender === 'them');
console.log(theirReplies?.at(-1)?.text);

// InMail reply (Sales Navigator route): use nvSyncConversation and type 'nv'.
const s2 = await linkedapi.nvSyncConversation.execute({ personUrl });
await linkedapi.nvSyncConversation.result(s2.workflowId);
const inmail = await linkedapi.pollConversations([{ personUrl, type: 'nv' }]);

# Standard reply (connection route): sync once, then poll the "st" thread.
s1 = linkedapi.sync_conversation.execute(SyncConversationParams(person_url=person_url))
linkedapi.sync_conversation.result(s1.workflow_id)
result = linkedapi.poll_conversations(
    [ConversationPollRequest(person_url=person_url, type="st")]
)
messages = result.data[0].messages if result.data else []
their_replies = [m for m in messages if m.sender == "them"]
if their_replies:
    print(their_replies[-1].text)

# InMail reply (Sales Navigator route): use nv_sync_conversation and type "nv".
s2 = linkedapi.nv_sync_conversation.execute(NvSyncConversationParams(person_url=person_url))
linkedapi.nv_sync_conversation.result(s2.workflow_id)
inmail = linkedapi.poll_conversations(
    [ConversationPollRequest(person_url=person_url, type="nv")]
)

Prefer the shell? The CLI runs the same flow, and the AI-agent surfaces – the MCP server and ready-made skills – expose it to Claude Code, Cursor, and Codex.

linkedin connection status https://www.linkedin.com/in/john-doe          # connected | pending | notConnected
linkedin connection send   https://www.linkedin.com/in/john-doe --note "Hi! Would love to connect."
linkedin message send      https://www.linkedin.com/in/john-doe "Thanks for connecting - quick question..."
linkedin navigator message send https://www.linkedin.com/in/john-doe "Hi..." --subject "Quick question"
linkedin message get       https://www.linkedin.com/in/john-doe --json   # wraps sync + poll to read replies

Where this flow ends is deliberate: it gets a message sent and the reply back into your system. What the follow-up should say, and when to send it, is outreach strategy – see our guide to LinkedIn cold outreach for the copy, timing, and sequence design. For method-by-method reference, see the docs for sending messages, connection requests, checking connection status, and working with conversations, or the SDK pages for sendMessage, nvSendMessage, sendConnectionRequest, checkConnectionStatus, syncConversation, nvSyncConversation, and pollConversations.

Automate the whole inbox (monitor every reply)

The loop above reads a reply when you already know the person. To automate messaging at the inbox level – catch every incoming message across all your conversations, then route, tag, or reply to it – switch on whole-inbox monitoring instead of syncing people one by one. Enable it once per account with syncInbox (or nvSyncInbox for the Sales Navigator inbox), then pollInbox returns every new message across every thread, each with the personUrl to reply to and a sender of us or them.

// Enable whole-inbox monitoring once per account.
const sync = await linkedapi.syncInbox.execute();
await linkedapi.syncInbox.result(sync.workflowId);

// Poll only what arrived since your last run, using a cursor you persist.
// Without `since`, pollInbox returns everything captured - so you would
// reprocess (and re-reply to) old messages on every run.
const since = await loadCursor();                  // your storage; undefined on first run
const { data } = await linkedapi.pollInbox({ type: 'st', since });
for (const m of data?.messages ?? []) {
  if (m.sender !== 'them') continue;               // inbound only
  const reply = await linkedapi.sendMessage.execute({ personUrl: m.personUrl, text: 'Thanks for the reply!' });
  await linkedapi.sendMessage.result(reply.workflowId);
}
// Advance the cursor to the newest message (pollInbox returns newest-first).
if (data?.messages.length) await saveCursor(data.messages[0].time);

# Enable whole-inbox monitoring once per account.
sync = linkedapi.sync_inbox.execute()
linkedapi.sync_inbox.result(sync.workflow_id)

# Poll only what arrived since your last run, using a cursor you persist.
# Without `since`, poll_inbox returns everything captured - so you would
# reprocess (and re-reply to) old messages on every run.
since = load_cursor()                              # your storage; None on first run
result = linkedapi.poll_inbox(InboxPollRequest(type="st", since=since))
messages = result.data.messages if result.data else []
for m in messages:
    if m.sender != "them":                         # inbound only
        continue
    reply = linkedapi.send_message.execute(
        SendMessageParams(person_url=m.person_url, text="Thanks for the reply!")
    )
    linkedapi.send_message.result(reply.workflow_id)
# Advance the cursor to the newest message (poll_inbox returns newest-first).
if messages:
    save_cursor(messages[0].time)

On the shell it is linkedin inbox sync once (add --nv for the Sales Navigator inbox), then linkedin inbox get --since <timestamp>. Poll with an advancing since, or skip polling entirely and subscribe to inbox webhook events for push delivery. This stays the mechanics layer – detecting and retrieving the message; what an auto-reply should actually say still belongs to your outreach strategy.

LinkedIn message and connection limits (staying safe)

LinkedIn does not publish exact message or connection-request limits, so treat the numbers you see online as guardrails, not gospel, and expect them to move with your account's age and standing. Third-party trackers land in a similar ballpark. For connection requests, ZELIQ's 2026 automation guide suggests roughly 20-40 a day (100-200 a week), while PhantomBuster, as of its July 2026 update, puts free and Premium accounts nearer 100 a week. For direct messages, ZELIQ's 2026 guide suggests about 30-60 a day, and PhantomBuster, as of July 2026, cites roughly 100 a week on a free account and 150 on Premium – all unofficial observations, not published caps. Our own breakdowns of the connection request limit and LinkedIn's limits go deeper.

The safer way to automate is to stay well inside those bounds on your own account. Linked API is built for exactly that: every action runs on your own account through a human-paced cloud browser, not a blast queue, and it surfaces LinkedIn's own limit signals instead of steamrolling them. Your code receives messagingNotAllowed when you are not connected or messaging is restricted, noteLimitExceeded when a free account runs out of personalized invitation notes, and requestNotAllowed when you approach LinkedIn's request limits – so you can back off automatically. It works within our safety model, and it returns profile, company, and post data – not emails or phone numbers.

When a no-code tool is the better choice

Code is not always the answer. If you want a point-and-click campaign builder, a visual sequence editor, and a shared team inbox – and you never want to touch an SDK – a no-code tool (the Dripify / HeyReach / Waalaxy class) will get you live faster. Those products are a good fit when the standard "connect, then follow up on a schedule" campaign is all you need and a closed UI is acceptable.

Linked API is the better choice when you want messaging as a primitive inside your own stack: triggered by events in your CRM, branched on your own logic, wrapped in your product, or driven by an AI agent. You trade a visual builder for full control and embeddability. Start from the installation guide and the CLI quickstart.

Frequently Asked Questions (FAQ)

Want to run the connect-to-reply flow on your own account, inside your own stack? Start with Linked API – the same actions across the API and SDKs, CLI, MCP server, and ready-made skills, on your own account and at a human pace.