linkedin-agent-cli 0.1.8__tar.gz → 0.1.9__tar.gz

{linkedin_agent_cli-0.1.8 → linkedin_agent_cli-0.1.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: linkedin-agent-cli
-Version: 0.1.8
+Version: 0.1.9
 Summary: Django-free library and CLI for LinkedIn platform mechanics over a bound browser session (Voyager API + Playwright).
 Project-URL: Homepage, https://github.com/eracle/linkedin-cli
 Project-URL: Repository, https://github.com/eracle/linkedin-cli
@@ -52,7 +52,7 @@ it behaves like a human session instead of a cookie-only scraper.
   not a brittle one-shot form fill.
 - **Language-agnostic.** Anything that can run a subprocess and parse JSON can
   drive LinkedIn — Python, Node, Go, shell, or an AI agent. No SDK lock-in.
-- **Tiny surface.** Eight verbs, four dependencies, zero web framework. It knows
+- **Tiny surface.** Nine verbs, four dependencies, zero web framework. It knows
   about *a LinkedIn page and a browser* — nothing else.
 
 ## 📦 Install
@@ -85,6 +85,7 @@ linkedin-cli login                                    # authenticate the session
 linkedin-cli search "head of growth" --network first  # discover → handles
 linkedin-cli profile alice-smith                      # scrape a profile
 linkedin-cli profile alice-smith --json > alice.json  # save the full record
+linkedin-cli contact-info alice-smith                 # email / phone (if exposed)
 linkedin-cli status  alice-smith                      # Connected / Pending / Qualified
 linkedin-cli connect alice-smith                      # send a connection request
 linkedin-cli message alice-smith --text "Hi Alice 👋"
@@ -106,6 +107,7 @@ so you can clear it by hand, then carry on.
 | `whoami` | Who is this session logged in as (no login flow) | `{self}` |
 | `search <kw> [--network first/second/third] [--page N]` | People search → matching profile handles | `{query, page, network, profiles[]}` |
 | `profile <id>` | Scrape a profile (positions, education, location, …); `--raw` adds the raw Voyager blob | full `LinkedInProfile` |
+| `contact-info <id>` | Email / phone from the "Contact info" overlay (only what the member exposes — usually 1st-degree); `--raw` adds the raw RSC payload | `{public_identifier, email, emails[], phone_numbers[]}` |
 | `status <id>` | Connection state | `{public_identifier, state}` |
 | `connect <id>` | Send a connection request (no note) | `{public_identifier, state}` |
 | `message <id> --text …` | Send a direct message | `{public_identifier, sent}` |
@@ -161,7 +163,10 @@ The discovery → outreach loop an agent runs: **`search` → `profile` / `statu
   database**. One session = one LinkedIn account.
 - **Voyager API** — reads (`profile`, `thread`, `status`) call LinkedIn's private
   Voyager endpoints from inside the authenticated page (`fetch`), then parse the
-  JSON — fast and structured, no DOM scraping where an API exists.
+  JSON — fast and structured, no DOM scraping where an API exists. `contact-info`
+  forges the same server-driven-UI (RSC) POST the web app fires for the "Contact
+  info" overlay and parses the returned stream — same fetch-from-page technique,
+  different endpoint.
 - **Page-state auth machine** — `classify_page()` judges the live page by URL
   *path* only (so a `/login?...redirect=/feed/` URL never reads as the feed), and
   each transition asserts its pre/post state, raising on an illegal jump. Login,

{linkedin_agent_cli-0.1.8 → linkedin_agent_cli-0.1.9}/README.md

@@ -26,7 +26,7 @@ it behaves like a human session instead of a cookie-only scraper.
   not a brittle one-shot form fill.
 - **Language-agnostic.** Anything that can run a subprocess and parse JSON can
   drive LinkedIn — Python, Node, Go, shell, or an AI agent. No SDK lock-in.
-- **Tiny surface.** Eight verbs, four dependencies, zero web framework. It knows
+- **Tiny surface.** Nine verbs, four dependencies, zero web framework. It knows
   about *a LinkedIn page and a browser* — nothing else.
 
 ## 📦 Install
@@ -59,6 +59,7 @@ linkedin-cli login                                    # authenticate the session
 linkedin-cli search "head of growth" --network first  # discover → handles
 linkedin-cli profile alice-smith                      # scrape a profile
 linkedin-cli profile alice-smith --json > alice.json  # save the full record
+linkedin-cli contact-info alice-smith                 # email / phone (if exposed)
 linkedin-cli status  alice-smith                      # Connected / Pending / Qualified
 linkedin-cli connect alice-smith                      # send a connection request
 linkedin-cli message alice-smith --text "Hi Alice 👋"
@@ -80,6 +81,7 @@ so you can clear it by hand, then carry on.
 | `whoami` | Who is this session logged in as (no login flow) | `{self}` |
 | `search <kw> [--network first/second/third] [--page N]` | People search → matching profile handles | `{query, page, network, profiles[]}` |
 | `profile <id>` | Scrape a profile (positions, education, location, …); `--raw` adds the raw Voyager blob | full `LinkedInProfile` |
+| `contact-info <id>` | Email / phone from the "Contact info" overlay (only what the member exposes — usually 1st-degree); `--raw` adds the raw RSC payload | `{public_identifier, email, emails[], phone_numbers[]}` |
 | `status <id>` | Connection state | `{public_identifier, state}` |
 | `connect <id>` | Send a connection request (no note) | `{public_identifier, state}` |
 | `message <id> --text …` | Send a direct message | `{public_identifier, sent}` |
@@ -135,7 +137,10 @@ The discovery → outreach loop an agent runs: **`search` → `profile` / `statu
   database**. One session = one LinkedIn account.
 - **Voyager API** — reads (`profile`, `thread`, `status`) call LinkedIn's private
   Voyager endpoints from inside the authenticated page (`fetch`), then parse the
-  JSON — fast and structured, no DOM scraping where an API exists.
+  JSON — fast and structured, no DOM scraping where an API exists. `contact-info`
+  forges the same server-driven-UI (RSC) POST the web app fires for the "Contact
+  info" overlay and parses the returned stream — same fetch-from-page technique,
+  different endpoint.
 - **Page-state auth machine** — `classify_page()` judges the live page by URL
   *path* only (so a `/login?...redirect=/feed/` URL never reads as the feed), and
   each transition asserts its pre/post state, raising on an illegal jump. Login,

linkedin_agent_cli-0.1.9/src/linkedin_cli/actions/contact_info.py

@@ -0,0 +1,21 @@
+# linkedin/actions/contact_info.py
+import logging
+
+from ..api.client import PlaywrightLinkedinAPI
+
+logger = logging.getLogger(__name__)
+
+
+def get_contact_info(session, profile: dict):
+    """Fetch a member's contact details (email, phone) via the profile overlay."""
+    public_id = profile["public_identifier"]
+
+    session.ensure_browser()
+    session.wait()
+
+    api = PlaywrightLinkedinAPI(session=session)
+    logger.info("Fetching contact info → %s", public_id)
+    contact, raw = api.get_contact_info(public_id)
+    logger.info("Contact info – %s (email=%s)", public_id, bool(contact.get("email")))
+
+    return contact, raw

{linkedin_agent_cli-0.1.8 → linkedin_agent_cli-0.1.9}/src/linkedin_cli/api/client.py

@@ -7,6 +7,7 @@ from urllib.parse import urlencode
 from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
 
 from linkedin_cli.api.voyager import parse_linkedin_voyager_response, parse_connection_degree
+from linkedin_cli.api.sdui import parse_contact_info
 from linkedin_cli.url_utils import url_to_public_id
 from linkedin_cli.exceptions import (
     AuthenticationError,
@@ -180,3 +181,51 @@ class PlaywrightLinkedinAPI:
         self._check_profile_response(res, public_identifier)
 
         return parse_connection_degree(res.json())
+
+    # Server-driven-UI screen that renders the profile "Contact info" overlay.
+    SDUI_CONTACT_SCREEN = (
+        "com.linkedin.sdui.flagshipnav.profile.ProfileContactDetailsOverlay"
+    )
+
+    @retry(
+        stop=stop_after_attempt(3),
+        wait=wait_exponential(multiplier=2, min=2, max=30),
+        retry=retry_if_exception_type(IOError),
+        reraise=True,
+    )
+    def get_contact_info(self, public_identifier: str) -> tuple[dict, str]:
+        """Fetch a member's contact details (email, phone) from the overlay.
+
+        Forges the same server-driven-UI POST the web app fires when you open
+        a profile's "Contact info" overlay, and parses the RSC stream it
+        returns. Returns ``(parsed_dict, raw_text)``; only fields the member
+        exposes to your network appear — email is typically present only for
+        1st-degree connections.
+        """
+        screen = self.SDUI_CONTACT_SCREEN
+        url = (
+            "https://www.linkedin.com/flagship-web/rsc-action/actions/navigation"
+            f"?screenId={screen}&sduiid={screen}"
+        )
+        payload = json.dumps({
+            "clientArguments": {
+                "$type": "proto.sdui.actions.requests.RequestedArguments",
+                "payload": {"vanityName": public_identifier, "isVanityNameResolved": True},
+                "requestedStateKeys": [],
+                "requestMetadata": {"$type": "proto.sdui.common.RequestMetadata"},
+                "states": [],
+                "screenId": screen,
+            },
+            "isModal": True,
+        })
+
+        res = self.post(
+            url,
+            headers={"content-type": "application/json",
+                     "x-li-rsc-stream": "true", "accept": "*/*"},
+            data=payload,
+        )
+        self._check_profile_response(res, public_identifier)
+
+        text = res.text()
+        return parse_contact_info(text), text

linkedin_agent_cli-0.1.9/src/linkedin_cli/api/sdui.py

@@ -0,0 +1,34 @@
+"""Parsers for LinkedIn's server-driven-UI (RSC) responses.
+
+Some flagship-web surfaces — including the profile "Contact info" overlay —
+are rendered via server-driven UI: a POST returns an RSC stream (React flight
+format) rather than a Voyager JSON blob. These helpers pull the fields we care
+about out of that text payload.
+"""
+import re
+
+# Contact links in the payload surface as navigate actions, e.g.
+#   "url":"mailto:alice@example.com"   /   "url":"tel:+1555..."
+_MAILTO = re.compile(r"mailto:([^\"\\<>\s]+)")
+_TEL = re.compile(r"tel:([^\"\\<>\s]+)")
+
+
+def _unique(values: list[str]) -> list[str]:
+    """De-duplicate while preserving first-seen order."""
+    return list(dict.fromkeys(values))
+
+
+def parse_contact_info(rsc_text: str) -> dict:
+    """Extract contact details from a ProfileContactDetailsOverlay RSC payload.
+
+    Returns ``{email, emails, phone_numbers}``. ``email`` is the first address
+    found (or ``None``). Only fields the member exposes to your network appear —
+    email is typically present only for 1st-degree connections.
+    """
+    emails = _unique(_MAILTO.findall(rsc_text))
+    phone_numbers = _unique(_TEL.findall(rsc_text))
+    return {
+        "email": emails[0] if emails else None,
+        "emails": emails,
+        "phone_numbers": phone_numbers,
+    }

{linkedin_agent_cli-0.1.8 → linkedin_agent_cli-0.1.9}/src/linkedin_cli/cli.py

@@ -122,6 +122,12 @@ def _human_profile(result: dict) -> str:
     return "\n".join(lines)
 
 
+def _human_contact_info(result: dict) -> str:
+    lines = [f"email: {result.get('email') or '—'}"]
+    lines += [f"phone: {p}" for p in (result.get("phone_numbers") or [])]
+    return "\n".join(lines)
+
+
 def _human_thread(result: dict) -> str:
     messages = result.get("messages")
     if not messages:
@@ -151,6 +157,7 @@ _HUMAN = {
     "connect": _human_state,
     "message": _human_sent,
     "profile": _human_profile,
+    "contact-info": _human_contact_info,
     "thread": _human_thread,
     "search": _human_search,
     "session-close": _human_closed,
@@ -210,6 +217,17 @@ def _verb_profile(session, args) -> dict:
     return out
 
 
+def _verb_contact_info(session, args) -> dict:
+    from linkedin_cli.actions.contact_info import get_contact_info
+
+    profile = _handle_to_profile(args.handle)
+    contact, raw = get_contact_info(session, profile)
+    out = {"public_identifier": profile["public_identifier"], **contact}
+    if args.raw:
+        out["_raw"] = raw
+    return out
+
+
 def _verb_status(session, args) -> dict:
     from linkedin_cli.actions.status import get_connection_status
 
@@ -256,6 +274,7 @@ _VERBS = {
     "login": _verb_login,
     "whoami": _verb_whoami,
     "profile": _verb_profile,
+    "contact-info": _verb_contact_info,
     "status": _verb_status,
     "connect": _verb_connect,
     "message": _verb_message,
@@ -351,6 +370,11 @@ def build_parser() -> argparse.ArgumentParser:
     p_profile.add_argument("handle", help=handle_help)
     p_profile.add_argument("--raw", action="store_true", help="Also emit the untouched Voyager blob under _raw")
 
+    p_contact = sub.add_parser("contact-info", parents=[common],
+                               help="Fetch the member's contact info (email, phone) from the Contact info overlay")
+    p_contact.add_argument("handle", help=handle_help)
+    p_contact.add_argument("--raw", action="store_true", help="Also emit the untouched RSC payload under _raw")
+
     sub.add_parser("status", parents=[common],
                    help="Report the connection state with the member: Connected, Pending, or Qualified"
                    ).add_argument("handle", help=handle_help)