The LinkedIn messaging API for DMs, InMails and invites.

Yes. The Edges Actions API covers the outreach surface most product teams need: sending connection requests (with or without a note), direct messages on existing 1st-degree conversations, follow-up messages, and reading inbox threads. Each capability is a typed action with documented inputs and JSON responses, so you integrate it the same way you integrate any other internal microservice.

For messaging and other engagement actions, yes — you connect a LinkedIn identity, either by passing a cookie or by logging in with email and password. Those actions run in `direct` mode against that connected seat: you don't send DMs or connection requests from the managed session pool, because outreach only makes sense coming from a real, named account. The managed pool is for reads (profiles, companies, search). Once the seat is connected, we still handle rate limits and ramp-up on it.

Three paths, same result: a connected identity that engagement Actions run against in `direct` mode. Pass a cookie, log in with email and password, or use the Edges Chrome extension. Reads (profiles, companies, search) can stay on the managed session pool; outreach never does.

Yes, InMail sending is exposed as an action for accounts that have InMail credits on their LinkedIn plan (Recruiter, Sales Navigator, or Premium). You pass the recipient, subject, and body, and Edges routes the send through the linked account. Responses to InMails land in the same conversation object you can poll via extract-conversations Actions (live or async with callbacks).

Not as a regular DM. LinkedIn only lets you message 1st-degree connections in the inbox. Send a connection request first (linkedin-connect-profile), then message after they accept. To reach someone you are not connected to, use InMail on a Premium, Sales Navigator, or Recruiter seat that still has credits.

Unipile is a unified inbox API — LinkedIn as one channel among email and WhatsApp. Edges is LinkedIn-native: DMs, InMails, invites, search, and enrichment share the same auth, identity pool, and rate shaping. We manage session health and per-seat limits (ramp-up, daily budgets, 429s) so you don't have to; Unipile leaves that operational surface to you. You also get Sales Navigator, scheduled timing patterns built with Actions, and a typed action catalog Unipile doesn't ship. Side-by-side: https://edges.run/compare/unipile

Phantombuster runs scheduled browser phantoms. Edges is a versioned HTTP API: typed Actions, structured errors, callbacks, CI mocks. Reads can run on the managed session pool; outreach runs on a seat you connect, with per-identity rate budgets and ramp-up. Side-by-side: https://edges.run/compare/phantombuster

Rate shaping is enforced per connected account, not per API key. Published daily defaults: connect 25 Classic / 30 Sales Nav; message 50 / 250; profile visits 80 / 500; InMail follows your LinkedIn plan credits. Classic accounts can attach a personalized connection note on 5 invites per month — after that LinkedIn drops the note silently. New identities ramp automatically. The API returns 429 with Retry-After and X-RateLimit-* headers so you can back off cleanly.

Engagement Actions — connect, message, InMail, extract-conversations, reactions — are free when you run them with an engagement identity. Set type: "engagement" when you create the identity. You still pay for the seat you connect and you still sit inside per-identity LinkedIn limits. Reads (profiles, companies, search) use the credit pool.

LinkedIn's terms prohibit certain patterns of automated scraping and spam but allow a range of legitimate integrations; interpretation depends heavily on your specific use case, volume, and how you handle user consent. Edges provides rate shaping, per-account pacing, and opt-out-friendly primitives that make it easier to stay inside acceptable patterns, but ToS compliance ultimately rests with you as the operator. We recommend running a legal review before you ship high-volume outbound and instrumenting your own abuse signals on top of ours.

The official path is OAuth through a LinkedIn partner application — typically the Community Management API, which is built for pages and organizations, not member DMs, invites, and InMails at product depth. Partner approval is a separate process with its own wait and scope. Edges is a third-party Actions API on a seat you connect (cookie, email + password, or Chrome extension). You get DMs, invites, InMails, inbox extract, and Sales Nav on one key, without LinkedIn partner approval. You own ToS compliance; we pace and ramp.

No. Edges is not related to LinkedIn and is not an official LinkedIn product. We do not offer OAuth through LinkedIn's partner program. You connect a LinkedIn identity you already operate, and engagement Actions run in direct mode on that seat.

Building means you own selectors, sessions, anti-bot posture, per-seat pacing, and a parsing layer per LinkedIn surface — plus on-call when LinkedIn changes a page. Edges already runs that operational layer: identity pool, ramp-up, 429 semantics, typed Actions. Year-one math and the hybrid pattern (Edges for production outreach, in-house for one-off research) are on https://edges.run/build-vs-buy

Every outbound send returns a linkedin_thread_id. Persist it and reuse it for follow-up sends so reporting stays keyed to one conversation. To pick up replies, schedule linkedin-extract-conversations (async or schedule) and deliver via callback.url, or poll GET /v1/runs/{run_uid}/outputs and diff threads in your app. There is no packaged message.received event.

Not as a packaged message.received event bus. Async and schedule Action runs (including extract-conversations) deliver results to your callback URL, or you poll GET /runs/{run_uid}/outputs. For ongoing inbox sync, schedule linkedin-extract-conversations and diff threads in your app — same callback / outputs path as every other Action. Integration webhooks cover AUTH_EXPIRED on the connected seat, not inbound DMs.

A message.received bus would push each inbound DM as it lands. Edges does not ship that. You schedule or run linkedin-extract-conversations, pass callback.url with on: "final" (or "all"), then fetch GET /v1/runs/{run_uid}/outputs and diff. Same callback contract as every other Action — documented at https://docs.edges.run/v1/runs/callbacks

No. LinkedIn's official (Marketing / Partner) API does not expose general 1:1 messaging — there's no public endpoint to send a DM, InMail, or connection request for most developers. Edges fills that gap: send messages, InMails, and invites on a LinkedIn seat you connect, as a REST API with managed pacing. Start with Message LinkedIn Profile.

Yes. Send connection requests — with or without a note — via Connect LinkedIn Profile, and manage the queue by bulk-accepting or withdrawing pending invitations with Accept pending LinkedIn invitations. Every call runs on your connected seat with per-identity pacing.

Yes — Edges is a REST Actions API built for agents. A single call sends a DM, InMail, or connection request on your connected seat, and per-seat rate limits with automatic ramp-up keep an agent from burning the account. Replies come back via webhooks and callbacks, so an agent can run a full multi-touch sequence with Workflows.