LinkedIn messaging API for product teams
A LinkedIn messaging API should let you send DMs, InMails, and connection requests from your own product—not a dashboard, not a Chrome extension, not a drag-and-drop automation tool. Edges exposes the full messaging surface as typed actions behind one REST endpoint, with managed sessions your app never has to babysit.
Built for developers embedding LinkedIn reach into prospecting tools, AI sales agents, recruiting platforms, and customer re-engagement flows.
Search demand for a LinkedIn DM API or LinkedIn InMail API tells you something about the buyer: they are not looking for another point-and-click outreach app. They are building something—an AI agent that follows up with qualified leads, a recruiting platform that needs to reach passive candidates, a customer success tool that wants to ping dormant champions when they change jobs. For them, outreach is a feature inside their product, not the product itself. That is exactly the integration shape Edges is designed for.
The usual options fall apart under that brief. Browser extensions assume a human is at the keyboard and a cookie lives in Chrome; they cannot power a server-side agent that needs to act on behalf of thousands of connected accounts. Workflow builders like Phantombuster run phantoms on a schedule—fine for ad-hoc growth hacks, painful when you need to embed messaging logic inside your own product with your own retry semantics and your own observability. Unified messaging APIs like Unipile solve breadth across channels, which is useful when you want one inbox surface, but trades away the LinkedIn-specific depth your roadmap actually needs.
Edges sits at the intersection those teams want: LinkedIn-native, developer-facing, production-grade. The REST surface covers the full outreach lifecycle—invites, accepted-invitation follow-ups, 1st-degree DMs, InMail sends on Recruiter or Sales Navigator seats, and inbox reads for reconciliation. Every action is paired with webhook events so your systems react to replies and status changes without polling, and every response is shaped so your handlers can assert on field names instead of parsing strings. You can read the full action surface in the action library, see how the same auth model powers sibling pillars like LinkedIn enrichment and LinkedIn scraping workloads, and dig into endpoint-level detail in the documentation.
curl -X POST \
"https://api.edges.run/v1/actions/linkedin-send-invitation/run/live" \
-H "Content-Type: application/json" \
-H "X-API-Key: <YOUR_API_KEY>" \
-d '{
"account_id": "acc_01HF...",
"input": {
"linkedin_profile_url": "https://www.linkedin.com/in/jane-doe",
"message": "Hi Jane — saw your post on RAG eval, would love to compare notes."
}
}'One action, one API key, one managed session — no cookie capture flow. linkedin-send-invitation
Why extensions and workflow builders break when you are building a product
A LinkedIn connection request API that lives in a Chrome extension is fine for one user sending a few invites a day. It stops being fine the moment you need to run that flow server-side for a customer who is asleep, or parallelize it across a thousand tenants, or pass a compliance review that asks where LinkedIn cookies are stored.
- Extensions require the user's browser to be open and the tab to be focused; your backend cannot rely on that.
- Workflow builders bundle logic and execution; you want logic in your own code with your own retries and your own queues.
- Cookie capture flows push a security boundary onto your product — every customer handing you a session is a liability.
- Browser phantoms run on someone else's schedule and break when selectors change; a typed API is a contract you can test.
What product teams actually want is the same developer ergonomics as Stripe or Twilio, applied to LinkedIn outreach: an HTTP call that does the thing, a response you can assert on, and webhook events for everything that happens after. That means retries are your concern only when you want them to be, idempotency is handled by passing a key you control, and observability is standard HTTP status codes plus typed error envelopes—not a browser console you cannot access from production.
{
"thread_id": "thr_01HGF9Q2...",
"message_id": "msg_01HGF9Q3...",
"account_id": "acc_01HF...",
"status": "sent",
"sent_at": "2026-04-21T09:42:11Z",
"recipient": {
"linkedin_profile_id": 123456789,
"full_name": "Jane Doe"
}
}Persist the thread ID in your DB; wire webhooks for replies and status changes.
One REST API for invites, DMs, InMails, and follow-ups
Edges treats every outreach capability as a first-class action. A LinkedIn outreach API is only useful if it covers the whole conversation lifecycle, so we expose connection invitations with optional notes, direct messages on existing 1st-degree threads, InMail sends for accounts with credits, follow-up sequencing on existing threads, and inbox read operations for state reconciliation.
Each action takes the same shape: an account_id that identifies which connected LinkedIn profile should run the send, a typed input payload, and a response that gives you a thread identifier and message ID you can persist. That uniformity means your orchestration layer—whether it is Temporal, an event-driven Python worker, or a Rails job—treats messaging like any other third-party HTTP integration.
The key architectural choice: managed sessions. You connect a LinkedIn account once through our hosted OAuth-style flow, and after that your app never touches a cookie. Your servers only ever see API keys and Edges identifiers.
That separation matters more than it looks on a diagram. Every team that tries to ship LinkedIn messaging from scratch ends up re-implementing the same rough layers: a headless browser fleet, a session manager, a proxy rotation strategy, and a queue with per-account pacing. Getting any one of those wrong means either silent failures or account strikes for your customers. Edges runs that infrastructure as the product, so your engineering hours go into the differentiating parts of your own app instead.
When product teams reach for this API
Four recurring shapes we see across design partners.
AI sales agents
Agents that qualify leads, book meetings, and handle replies need a send primitive that is fast, typed, and rate-shaped per account. Edges is the layer that turns an LLM decision—"send this follow-up now"—into a real message on the right thread, with the right pacing, without the agent ever handling credentials. The agent stays stateless; the sending engine, session pool, and pacing policy live on our side of the API.
Prospecting tools
GTM products that used to stop at "enriched list" now want to close the loop with in-product reach: send the first-touch invite, log the reply, trigger the next step. Shipping that yourself means owning a session pool, a sending engine, per-account pacing, and a webhook consumer for replies. Buying it from Edges means one REST call per action and one webhook URL for everything that comes back.
Recruiting platforms
ATS and sourcing products need to reach passive candidates where they are—inside LinkedIn—without shipping a browser extension to every recruiter. A server-side InMail and messaging API lets a recruiting platform offer native outreach as a feature, not a workaround. Recruiter seats keep their InMail credits; your platform adds templating, tracking, and reporting on top.
Customer success re-engagement
When a champion changes jobs, email goes dark. CS tools that detect the signal and reach out on LinkedIn keep the relationship warm. Edges pairs cleanly with signal-detection flows so re-engagement is a pipeline step, not a manual task in someone's Notion board. One action fires the note; the next webhook tells you whether it turned into a conversation.
Safety, rate shaping, and the ToS conversation
Managed sessions and per-account pacing
Every connected LinkedIn account gets its own rate budget enforced server-side, because LinkedIn scopes abuse signals to the user profile rather than your API key. Defaults match human-paced outreach—low-tens of invitations and a few hundred inbox actions per account per day—and you can request tuned ceilings for verified workloads with a brief review.
Managed sessions also mean your app never stores a LinkedIn cookie. Security review gets shorter; your product surface area gets smaller.
Compliance is a use-case conversation
LinkedIn's terms prohibit certain automation and spam patterns but permit a range of legitimate product integrations. Whether a given use case stays inside acceptable bounds depends on volume, consent, personalization, and how you handle opt-outs. Edges provides the primitives—rate shaping, opt-out-friendly sequencing, webhook cancellation on reply—but the operating decisions belong to you.
Enterprise customers run these reviews with us as part of onboarding; Enterprise covers SOC2 posture, retention, and subprocessors.
How Edges differs from Unipile and Phantombuster
Teams evaluating a LinkedIn messaging API usually shortlist three shapes of vendor. Unified messaging APIs cover LinkedIn plus email, WhatsApp, and others; that is the right pick when channel breadth is the core requirement and you accept shallower LinkedIn depth. Workflow automation tools like Phantombuster run browser phantoms on a schedule; that works when the outcome is a growth experiment, not a product feature.
Edges is the third shape: a LinkedIn-native developer API. We do not cover email or WhatsApp, and we do not expose a workflow canvas. What we do cover is every meaningful LinkedIn action—enrichment, search, messaging, signals—through the same auth, the same session pool, the same observability, so you can build deep LinkedIn experiences without gluing three vendors together.
The practical consequence: if your roadmap is "ship LinkedIn as a first-class channel inside our product," the Unipile trade-off usually leaves you reimplementing LinkedIn-specific logic on top. If your roadmap is "automate a growth play for my team this quarter," Phantombuster may ship faster than a real integration. Edges is worth the spend when LinkedIn messaging is part of a product your customers pay you for and your engineering team owns the surface area.
If you want the side-by-side, see Edges vs. Unipile, Edges vs. Phantombuster, or browse the full compare hub.
LinkedIn messaging API FAQ
Developer-oriented answers to the questions we hear on most first calls.
Send LinkedIn messages from your product, not a dashboard
Book a demo to map your outreach flows to Edges actions, pull enrichment and messaging into the same pipeline, or start from the docs and library if you prefer to prototype first.