💬 LinkedIn Conversation Scraper With Named Senders & Thread Members

Pull every conversation from your LinkedIn inbox into structured JSON — and this time everyone in the thread is named. Every participant in a group chat comes back with their name and profile link, and every message is labelled with the name of the person who actually sent it. Same requests, same cost — the base scraper already downloads this data and throws it away.

---

✨ What's new here

The base actor only ever surfaces one other participant (pick_other_participant()), and every message is labelled "me" or the literal string "her/him" — fine for a 1:1 chat, useless for a group thread. This variant adds three toggles, all on by default, so a bare run already delivers the upgrade:

• 👥 include_thread_members — every person in the conversation, named, with profile link, headline, connection degree, pronouns and photo. Plus the thread's own title, its link, and who created it.
• ✍️ name_message_senders — every message gets sender_name + sender_profile_url instead of just "me" / "her/him". This is a lookup against the roster the actor already has, not an extra request.
• 🎯 only_with_participants — keep only conversations that include at least one named person. Works against the full roster, so it finds someone in a five-person group chat even when they aren't the person LinkedIn happens to list first — the base actor can't do that; it only ever sees one participant.

No extra HTTP requests. No extra charges. The roster and the sender names live inside the same conversationParticipants[] / message payload the base actor already downloads for every conversation — this variant just stops discarding it.

---

⚠️ Read this before you rely on participants or who

The base actor's original two fields are kept exactly as they were, unchanged, in the same rows that now also carry the full roster:

• participants is still a one-element array — whichever person LinkedIn happened to list first.
• who / last_message_who still say "me" or the literal string "her/him" — never a name.

That is not a bug in this variant; it is the original actor's output, preserved for backward compatibility. Use thread_members for the roster and messages[].sender_name for who said what. Those are the new fields below.

---

🔑 Key Features

Feature	What it does
📥 Inbox sweep	Primary, All, Other, Archive, Spam
🔎 Filters	InMail, Starred, Unread only
💬 Per-thread depth	Configurable max messages per conversation
👥 Full thread roster	Every participant, named, with profile link, headline, distance, pronouns, photo
✍️ Named message senders	Every message labelled with who actually sent it, not just "me"/"her/him"
🎯 Participant filter	Keep only threads that include specific people, checked against the whole roster
✨ Profile enrichment	Headline + distance + pronouns + picture, straight from the API
🌐 Tiered proxy fallback	Direct → Residential (auto, on block)
📅 Date filters	Today-only or older-than-cutoff
💾 Live saving	Actor.push_data per conversation — no data loss on crash

---

📥 Input

Base fields (unchanged from the original actor):

Field	Type	Required	Description
🔐 li_at	string	Yes	Your li_at cookie from www.linkedin.com (treat as a password)
📥 list_type	string	No	PRIMARY_INBOX (default), INBOX, SECONDARY_INBOX, ARCHIVE, SPAM
🔎 filter	string	No	"" (none), INMAIL, STARRED, UNREAD
💬 max_convs	integer	No	Max conversations to scrape (0 = unlimited)
📝 max_messages_per_conv	integer	No	Max messages per conversation (0 = unlimited, most-recent kept)
📅 today_limit	boolean	No	If true, only today's conversations
🗓️ date_limit	string	No	YYYY-MM-DD — skip conversations older than this date
⚡ concurrency	integer	No	Parallel thread-message fetches (default 5)
🔁 max_retries	integer	No	Retries per API request on 429/5xx (default 3)
🌐 proxyConfiguration	object	No	Defaults to direct; auto-escalates to residential if LinkedIn blocks

New fields (this variant):

Field	Type	Default	Description
👥 include_thread_members	boolean	true	Emit thread_members, thread_title, thread_url. Turn off for smaller rows on a 1:1-only inbox. (creator_name/creator_profile_url are always emitted — base finalize made them unconditional, matching the base engine's own value.)
✍️ name_message_senders	boolean	true	Emit messages[].sender_name / .sender_profile_url and last_message_sender_name / .._url.
🎯 only_with_participants	array of strings	[]	Keep only conversations whose roster matches at least one name / profile link (case-insensitive, partial match). Empty = keep everything.

Example input

{
  "li_at": "AQEDAU...your_cookie...",
  "list_type": "PRIMARY_INBOX",
  "filter": "",
  "max_convs": 10,
  "max_messages_per_conv": 25,
  "today_limit": false,
  "proxyConfiguration": { "useApifyProxy": false },
  "include_thread_members": true,
  "name_message_senders": true,
  "only_with_participants": []
}

With nothing configured beyond li_at, the bare run already gives you every member of each thread by name and every message labelled with its sender — that is the point of this variant.

---

📤 Output

Each dataset record is one conversation. All 15 base fields are unchanged — same names, order, nesting, including the ones kept for backward compatibility. New fields are appended after _conversation_id.

{
  "participants": [
    {
      "url": "<redacted>",
      "distance": "DISTANCE_1",
      "pronoun": "<redacted>",
      "picture": "<redacted>",
      "firstname": "<redacted>",
      "lastname": "<redacted>",
      "headline": "<redacted>",
      "entityUrn": "ACoAA..."
    }
  ],
  "status": "ACTIVE",
  "unread_count": 0,
  "last_read_at": "2026-08-14 09:12:03",
  "last_activity_at": "2026-08-15 17:41:22",
  "is_group_chat": true,
  "creator": "ACoAA...",
  "created_at": "2026-08-11 10:02:55",
  "messages": [
    {
      "content": "<redacted>",
      "date": "2026-08-15 17:41:22",
      "who": "her/him",
      "sender_name": "<redacted>",
      "sender_profile_url": "<redacted>",
      "sender_urn": "ACoAA..."
    }
  ],
  "total_messages": 5,
  "last_message_date": "2026-08-15 17:41:22",
  "last_message_content": "<redacted>",
  "last_message_who": "her/him",
  "days_from_today": 1,
  "_conversation_id": "2-XXXX==",

  "thread_members": [
    {
      "url": "<redacted>", "distance": "SELF", "pronoun": null, "picture": "<redacted>",
      "firstname": "<redacted>", "lastname": "<redacted>", "headline": "<redacted>",
      "entityUrn": "ACoAA...", "is_self": true
    },
    {
      "url": "<redacted>", "distance": "DISTANCE_1", "pronoun": "<redacted>", "picture": "<redacted>",
      "firstname": "<redacted>", "lastname": "<redacted>", "headline": "<redacted>",
      "entityUrn": "ACoAA...", "is_self": false
    }
  ],
  "thread_title": "<redacted>",
  "thread_url": "<redacted>",
  "creator_name": "<redacted>",
  "creator_profile_url": "<redacted>",
  "last_message_sender_name": "<redacted>",
  "last_message_sender_url": "<redacted>"
}

New fields, one line each

Field	Description
thread_members[]	Every conversation participant, named — same 8-key shape as participants[], plus is_self
thread_title	The conversation's own title (a group chat's name). Usually null on 1:1 threads.
thread_url	Direct link to the conversation, passed through exactly as LinkedIn sends it; null if absent.
creator_name / creator_profile_url	Who created the thread, named via the same roster join; null if they've since left it.
messages[].sender_name / .sender_profile_url	Who sent this message, joined from the roster — null if the sender has since left the thread (their id is still kept in sender_urn).
messages[].sender_urn	The sender's id, always present regardless of the naming toggle.
last_message_sender_name / last_message_sender_url	Mirrors the last message's sender fields.

None of these fields is calculated, scored, ranked or compared to a previous run. Every one is a value LinkedIn sent, or reached by matching an id LinkedIn sent to a record LinkedIn sent in the same response.

⚠️ Honest limits

• The roster and the transcript can legitimately disagree. The actor fetches only the messages allowed by max_messages_per_conv (default 5, most-recent kept), and it fetches only one page of messages per conversation. A thread can list five named members while the transcript only contains messages from two of them. The member list is everyone in the thread; the messages are the most recent ones this actor collected — not every member will have a message in the row.
• Group-thread rosters with more than two people were verified in code, not in a live measured run at the time this variant shipped. The join logic (conversationParticipants[] → name) is the same array LinkedIn returns for a 1:1 thread, which was measured live and returned two fully-named participants — the design generalizes, but a specific large-group screenshot was not captured before release.
• A departed sender's name comes back null, not guessed — their id (sender_urn) is kept.
• only_with_participants filters after messages are already fetched (same place, same behavior as the base's own date filter) — filtered-out threads are not saved and therefore not charged, but the fetch itself still happens.

---

🚀 How to Use (Apify Console)

1. 🔓 Log in to Apify Console → Actors.
2. 🔍 Find LinkedIn Conversation Scraper With Named Senders & Thread Members and open it.
3. 🍪 Grab your li_at cookie:
   • Open linkedin.com in Chrome → press F12 → Application → Cookies → https://www.linkedin.com → copy the value of li_at.
4. 📝 Paste it into the 🔐 LinkedIn Session Cookie (li_at) field.
5. ⚙️ Configure inbox type, filter, limits, and proxy if needed. Leave 👥 / ✍️ on for the full roster + names.
6. ▶️ Click Start.
7. 📺 Watch the live log — each conversation is logged as it's saved.
8. 📂 Open the Dataset tab when the run finishes.
9. 📤 Export to JSON / CSV / XLSX / Excel.

💡 Tip: Start with max_convs = 5 to validate everything is working before launching a full sweep.

---

💰 Pricing

This actor is Pay-Per-Event (PPE): one row_result charge for every conversation actually saved to the dataset (i.e. it survives the date filter and only_with_participants, if set). You also pay the underlying Apify platform usage (compute units, proxies if used, dataset writes). include_thread_members and name_message_senders add no extra charge — the roster and sender names come from data already fetched as part of the same conversation.

---

❓ Frequently Asked Questions

Can I scrape group chats?

Yes. is_group_chat is reported straight from LinkedIn's API, and with include_thread_members on (default) every member of the group is returned by name in thread_members, with the thread's own title and link. Every message is labelled with its actual sender in messages[].sender_name. The original participants field is kept for backward compatibility and still only lists one person — use thread_members instead.

Why do participants and who still say "her/him"?

Those are the base actor's original fields, kept unchanged on purpose so nothing that reads this actor's existing output breaks. Use thread_members for the full roster and messages[].sender_name for who sent each message — those are this variant's actual upgrade.

Where do I find my li_at cookie?

Open linkedin.com, press F12, go to Application → Cookies → https://www.linkedin.com, and copy the Value of the li_at cookie. It looks like AQEDA.... Treat it like a password.

Will this work without a cookie?

No. LinkedIn's messaging endpoints all require an authenticated session. We use your cookie so the scraper sees the same inbox you do.

Can I scrape someone else's inbox?

No. The li_at cookie ties to whoever generated it. You can only scrape your own inbox.

Will LinkedIn ban my account?

Use sensible limits. Don't run dozens of large sweeps a day. Lower concurrency if you see warnings. Scraping your own inbox at human-realistic rates is the lowest-risk pattern. A session cookie copied onto an unfamiliar exit IP can get revoked quickly — this is a property of LinkedIn's session security, not something this actor controls.

---

⚠️ Cautions / Legal

• 📚 You may only scrape data your account is authorized to see (your own inbox).
• 🔐 Never share your li_at cookie publicly — it grants full access to your LinkedIn account.
• 📜 You are responsible for compliance with LinkedIn's User Agreement, GDPR, CCPA, and any other applicable law in your jurisdiction.
• 👥 This variant surfaces more third-party personal data than the base actor — every named member of every thread, not just one contact per row. That data comes from a response your own account already receives; the other members did not consent to it being exported. You are responsible for how you store, use, and retain it.
• 🤝 Don't use this to spam, harass, or unsolicited-message anyone — automated outreach violates LinkedIn's rules.
• 🚦 Respect rate limits — protect your account by keeping concurrency modest and max_convs reasonable.

---

Built with ❤️ on Apify • Documentation • Apify Console