---
type: trekresearch-brief
created: 2026-05-29
question: "As of 2026, can a personal LinkedIn profile self-serve post-level analytics via an API, are per-post saves visible in the native UI, and can a personal profile auto-publish via any API — with the exact constraints for a solo user without partner/company-page access?"
confidence: 0.86
dimensions: 4
mcp_servers_used: [tavily]
local_agents_used: []
external_agents_used: [docs-researcher, community-researcher, contrarian-researcher]
---

# Personal-Profile Analytics + Auto-Publish Boundaries (2026)

> Generated by trekresearch (standard external swarm: docs + community + contrarian; no
> Gemini — scoped to Topic 1) on 2026-05-29. Topic 2 of 3 for the linkedin-studio
> remediation. Feeds Phase-1 honest boundary statements + the Phase-2 saves honesty-fix.
> **Primary-sourced from Microsoft Learn (LinkedIn's canonical dev docs).**

## Research Question

As of 2026, can a personal LinkedIn profile self-serve post-level analytics via an API,
are per-post saves visible in the native UI, and can a personal profile auto-publish via
any API — with the exact constraints for a solo user without partner/company-page access?

## Executive Summary

**The audit's own boundary assumptions are partly wrong, and fixing them naively would
replace one false claim with another.** Three findings, all primary-sourced and
high-confidence: (1) a personal profile **CAN auto-publish self-serve** — `w_member_social`
is an Open Permission via the free "Share on LinkedIn" product, publishing immediately at
~150 posts/member/day; the plugin's clipboard-stop is a **design + Terms-of-Service
choice, not an API impossibility**. (2) Per-post **saves ARE visible** in native post
analytics (rolled out ~Sept 2025, count-only, no saver identity) **and** exposed via the
API's `POST_SAVE` metric (since version li-lms-2026-04) — so "saves aren't trackable" is
**stale/false**; the honest line is "visible in the UI, not self-serve via API." (3)
Post-level analytics via API **exist** (`memberCreatorPostAnalytics` / `r_member_postAnalytics`)
but sit behind the **vetted Community Management API** (verified organization + associated
LinkedIn Page + use-case review) — **not self-serve for a solo creator**; CSV export is the
practical floor, not the only technical path. **Key caveat:** every boundary statement
must be *dated* ("as of 2026-05") — this surface changed fast (saves went UI→API inside
~12 months).

## Dimensions

### D1. Post-level analytics API for personal profiles — Confidence: high

**External findings:**
- The endpoint exists: `GET /rest/memberCreatorPostAnalytics` ("Member Post Statistics"),
  permission `r_member_postAnalytics` (versions ≥ li-lms-202506). Finders `q=entity`
  (one post) and `q=me` (aggregated). Metrics: `IMPRESSION`, `MEMBERS_REACHED`, `RESHARE`,
  `REACTION`, `COMMENT` (since 2025-06) and — added **li-lms-2026-04** — `POST_SAVE`,
  `POST_SEND`, `LINK_CLICKS`, `PREMIUM_CTA_CLICKS`, `FOLLOWER_GAINED_FROM_CONTENT`,
  `PROFILE_VIEW_FROM_CONTENT`. (Video metrics are a separate endpoint
  `memberCreatorVideoAnalytics`; follower count is `memberFollowersCount` /
  `r_member_profileAnalytics`.) [learn.microsoft.com/.../members/post-statistics?view=li-lms-2026-05]
- **The access gate is the crux:** `r_member_postAnalytics` is listed **exclusively under
  the Community Management API** (a "Vetted Product") — never in the consumer Open
  Permissions. Community Management approval requires an approved use case, **verified
  organization**, verified domain, **an app verified by a LinkedIn Page associated with
  the same organization**, and (Standard tier) a privacy policy + screencast review.
  Dev-tier rate limits: 500 calls/app/24h, 100/member/24h. [learn.microsoft.com/.../increasing-access; .../community-management-app-review]
- The 2025 "LinkedIn opened Member Post Analytics to individuals" headline is true **only
  through approved partner platforms** (Metricool/Buffer/Hootsuite-class) that hold the
  approval — not by a creator calling the API directly. LinkedIn is also *tightening*:
  the read scope `r_member_social` (Member Post Management) is flatly **closed** — "not
  accepting access requests at this time due to resource constraints."

**Contradictions:** "CSV is the only way" (plugin/audit) is wrong at the *capability*
level (an API exists) but right at the *practical* level for a solo dev (the API is
org-vetted). **Resolution:** state "exists but partner-gated; not self-serve; CSV is the
practical floor for a solo creator," not "no API exists."

### D2. Per-post saves visibility — Confidence: high

**External findings:**
- **Native UI:** the official LinkedIn Help page on post analytics lists, under Social
  Engagement: Reactions, Comments, Reposts, **Saves** ("number of times members saved
  your post"), Sends — rolled out ~**Sept 2025**. **Count only, never saver identity.**
  Rollout was phased and historical backfill limited (older posts may show no saves).
  [linkedin.com/help/linkedin/answer/a516971; socialmediatoday.com/news/linkedin-adds-save-and-send-data-to-content-insights/759828/]
- **API:** `POST_SAVE` exposed via `memberCreatorPostAnalytics` from li-lms-2026-04 — but
  behind the same Community-Management gate as D1 (not self-serve).

**Resolution (sharpens the Q3 honesty-fix):** the honest downgrade is **NOT** "saves
can't be tracked." It is: *"saves are visible in your native LinkedIn post analytics
(since Sept 2025, count-only) but there is no self-serve API to pull them, so this tool
does not auto-ingest them — read them in LinkedIn directly."* The operator's decision (no
manual-entry feature) stands and is defensible: the number is human-readable but
programmatically out of reach + would be hand-typed and instantly stale.

### D3. Auto-publish from a personal profile — Confidence: high (capability) / the ToS line is the real boundary

**External findings:**
- **A personal profile CAN auto-publish, self-serve.** `w_member_social` is an **Open
  Permission** (no approval), granted by adding the free **"Share on LinkedIn"** product
  (filed under `.../integrations/self-serve/`). `POST /v2/ugcPosts` (or `/rest/posts`)
  with `lifecycleState: PUBLISHED` publishes **immediately, no human-in-the-loop**. Rate
  limit ~150 requests/member/day. Self-serve content types: text, image, video,
  article/URL share. [learn.microsoft.com/.../share-on-linkedin; .../getting-access]
- **Genuine limitations:** organic **carousels (ad-style) are NOT available** via API for
  a personal profile (sponsored only) — use **MultiImage** for swipeable images; **member
  document/PDF** posts and the modern `/rest/posts` *member* path are doc-ambiguous (don't
  promise without testing). You also **cannot self-serve read your own posts back**
  (`r_member_social` is restricted/closed) — capture the post URN from the publish
  response header instead.
- **Operational friction (real, first-hand):** 3-legged OAuth (one interactive auth);
  60-day access tokens / ~365-day refresh tokens that invalidate on revoke **or scope
  change** (`invalid_grant` footgun); a common `403 me.GET.NO_VERSION` trap (use
  `/userinfo` `sub`, not `/v2/me`); a placeholder company-page link required at app setup
  even for personal-only posting; "outdated docs everywhere." [marcusnoble.co.uk/2025-02-02-posting-to-linkedin-via-the-api/; github.com/linkedin-developers/linkedin-api-js-client/issues/35]
- **The real boundary is ToS, not capability:** `w_member_social` being "open" does not
  mean automated/scheduled posting is within LinkedIn's API Terms. The legitimate basis
  for the plugin's clipboard-stop is **(a) per-user OAuth + token-refresh operational
  overhead and (b) LinkedIn's Terms posture on automated posting** — not "the API can't
  do it."

**Resolution:** the plugin must **not** write "cannot auto-publish." Honest framing:
*"auto-publish to a personal profile is technically possible and self-serve (Share on
LinkedIn / `w_member_social`); the plugin deliberately stops at the clipboard — OAuth +
60-day-token overhead and LinkedIn's Terms on automated posting make human-in-the-loop
the safer default. A choice, not a wall."* (Verify current Platform/Marketing API Terms
language on automated personal posting before finalizing the wording.)

### D4. Dwell time exportability — Confidence: medium-high (organic boundary holds, with carve-outs)

**External findings:**
- For **organic personal posts**, there is **no creator-facing dwell metric** — not in the
  UI Help metric list, not in `memberCreatorPostAnalytics`. Dwell is an internal ranking
  signal only. [linkedin.com/help/linkedin/answer/a516971]
- **Carve-outs (so the claim isn't falsifiable):** (1) **video** posts expose **Watch
  time / Average watch time** (UI + member video API) — a real per-post depth metric, just
  not for non-video; (2) `averageDwellTime` exists in the **ads** `adAnalytics` API (paid
  campaigns only, methodology improved ~+25% in a 2026 change).

**Resolution:** "for organic posts, dwell is internal-only — no creator number; video
Watch time is the closest creator-visible depth proxy; a true dwell field exists but only
for paid ads." Do not say "LinkedIn has no dwell metric anywhere."

## External Knowledge

### Best Practice (official / primary)
Microsoft Learn (li-lms-2026-05) is authoritative. The self-serve set for a solo dev is
exactly three Open Permissions: `profile`, `email`, `w_member_social`. **Everything
analytics** is Community-Management-vetted. This single fact drives every honest boundary
statement.

### Known issues
The surface moves fast and docs lag the API (saves went invisible→UI→API in ~12 months;
`r_member_social` went from program to closed). Any boundary statement must be **dated**.
Practitioner reality adds friction (token fragility, the `/me` 403 trap) that makes
"feasible" ≠ "frictionless."

## Synthesis

1. **The audit's "honest scheduling boundary" finding (§5) was itself half-wrong.** It
   assumed the plugin "stops at the clipboard because it can't auto-publish." The truth:
   it *can* (self-serve), and the honest disclosure is about the **design + ToS choice**,
   not an impossibility. Phase 1's boundary prose must encode the *choice*, or it ships a
   brand-new false claim — exactly the failure mode this whole remediation exists to kill.

2. **The saves honesty-fix is a wording fix, not a "we can't" fix.** Saves are now
   visible in the UI. The accurate downgrade points the user to LinkedIn's own analytics
   for the number while being honest that the tool can't pull it. This keeps the operator's
   "no manual-entry" decision *and* avoids a stale "saves aren't trackable" claim.

3. **There is a latent, deliberately-deferred capability here.** Auto-publish is buildable
   self-serve. It is explicitly a **Non-Goal** of this remediation (operator: disclose
   boundaries, don't engineer them away). Worth a one-line "possible but intentionally not
   built (ToS + token overhead)" note so a future maintainer doesn't rediscover it as a
   "missing feature."

## Open Questions

- **Exact ToS language on automated/scheduled personal posting** — the load-bearing reason
  for the clipboard-stop. *Carry as: verify current Platform/Marketing API Terms before
  finalizing the boundary wording.* (Not a blocker for the plan; a finalize-time check.)
- **Member document/PDF + `/rest/posts` member-author path** — doc-ambiguous. Irrelevant
  unless a future version builds publishing; flag, don't resolve.

## Recommendation

For Phase 1 (honest boundaries) and Phase 2 (saves honesty-fix), write these **dated**
statements:

1. **Analytics API:** "A post-level analytics API for personal posts exists, but it's
   behind LinkedIn's vetted Community Management API (verified organization + LinkedIn
   Page + use-case review) — not self-serve for an individual. For a solo creator, CSV
   export is the practical path. (As of 2026-05.)"
2. **Saves:** "Saves are visible in your native LinkedIn post analytics (since ~Sept 2025,
   count-only). There's no self-serve API to pull them, so this tool doesn't track saves
   automatically — read them in LinkedIn directly." Remove any "saves (10x weight) are the
   highest-impact signal" claim presented *inside a report the tool populates*; reframe as
   strategy guidance pointing to the native number.
3. **Auto-publish:** "Auto-publishing to a personal profile is technically possible
   (self-serve `w_member_social`); this tool deliberately stops at the clipboard — OAuth +
   token-refresh overhead and LinkedIn's Terms on automated posting. A choice, not a
   limitation. (As of 2026-05.)" Reconcile the calendar/queue/"publish action" wording so
   it never implies the tool auto-posts.
4. **Dwell:** "Dwell time is an internal ranking signal — no creator-facing number for
   organic posts (video Watch time is the closest proxy)."

## Sources

| # | Source | Type | Quality | Used in |
|---|--------|------|---------|---------|
| 1 | [Member Post Statistics API (li-lms-2026-05)](https://learn.microsoft.com/en-us/linkedin/marketing/community-management/members/post-statistics?view=li-lms-2026-05) | official | high | D1, D2 |
| 2 | [Increasing Access — permissions table](https://learn.microsoft.com/en-us/linkedin/marketing/increasing-access?view=li-lms-2026-05) | official | high | D1 |
| 3 | [Community Management App Review](https://learn.microsoft.com/en-us/linkedin/marketing/community-management-app-review?view=li-lms-2026-05) | official | high | D1 |
| 4 | [Community Management Overview / FAQ (r_member_social closed)](https://learn.microsoft.com/en-us/linkedin/marketing/community-management/community-management-overview?view=li-lms-2026-05) | official | high | D1 |
| 5 | [Share on LinkedIn (self-serve)](https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/share-on-linkedin) | official | high | D3 |
| 6 | [Getting Access — Open Permissions](https://learn.microsoft.com/en-us/linkedin/shared/authentication/getting-access) | official | high | D3 |
| 7 | [Post analytics for your content — LinkedIn Help (Saves listed)](https://www.linkedin.com/help/linkedin/answer/a516971) | official | high | D2, D4 |
| 8 | [Social Media Today — LinkedIn adds Save/Send data (Sept 2025)](https://www.socialmediatoday.com/news/linkedin-adds-save-and-send-data-to-content-insights/759828/) | community | medium-high | D2 |
| 9 | [Refresh Tokens with OAuth 2.0](https://learn.microsoft.com/en-us/linkedin/shared/authentication/programmatic-refresh-tokens) | official | high | D3 |
| 10 | [Marcus Noble — Posting to LinkedIn via the API (first-hand)](https://marcusnoble.co.uk/2025-02-02-posting-to-linkedin-via-the-api/) | community | medium-high | D3 |
| 11 | [GitHub — linkedin-api-js-client #35 (403 /me trap)](https://github.com/linkedin-developers/linkedin-api-js-client/issues/35) | community | medium | D3 |
| 12 | [Recent Marketing API Changes (ads averageDwellTime)](https://learn.microsoft.com/en-us/linkedin/marketing/integrations/recent-changes?view=li-lms-2026-01) | official | high | D4 |
| 13 | [ConnectSafely — LinkedIn API guide 2026 (approval reality)](https://connectsafely.ai/articles/linkedin-api-complete-guide-2026) | community | low-medium | D1 |
