Why

About

This tool exists because of one closed permission.

The problem

You post something. Later you cannot find it. LinkedIn's own search has no "your posts" filter, and once a post is deleted it is unfindable there too.

So you go looking for a tool that keeps your post history. What you find instead:

  • LinkedIn's data export — a static archive, requested by hand, desktop-only, with a 72-hour download window. Not searchable, not ongoing.
  • Scheduling tools — Buffer, Hootsuite, Taplio, and the rest. Buffer and Hootsuite use the official API; several others drive a browser session, which risks the account. Hootsuite starts at $99/user/month to schedule posts on a platform that gives you a scheduler for free.
  • Unofficial CLIs — some are good, but they scrape with your session cookies. Some of their users report bans six months into apparently-clean automation.

One project came close: an MIT-licensed MCP server using the official API with a local SQLite log of created posts. As I read its source, it stored the post text with no way to query it, and its list_my_posts read only that local database — never LinkedIn — so anything posted before installing it was invisible. Worth checking its current source before taking this as current; it may have changed.

The specific thing that makes it impossible

LinkedIn has a permission called r_member_social for reading your own posts. It is not slow, not paid, and not partner-gated. It is closed — the documentation says it is not accepting access requests at this time.

That is the whole problem in one line. You can write to LinkedIn through an approved app, but no approved app can read back what it wrote. LinkedIn's own native scheduler does let you browse your history — as a web product with no API behind it.

The practical consequence: if you lose a post's ID at creation time, that post is gone. Not hidden, not archived — gone. Everything in postiee follows from taking that seriously.

What that implies for the design

  1. The post ID is the first-class concern. It comes from a response header because the body is empty. If it is missing, the tool fails loudly instead of reporting a success it cannot back up.
  2. The local record is the product, not a feature. SQLite with full-text search, because a log you cannot query is not a history.
  3. Nothing ships that cannot work. No comment command that 403s, no analytics stub. The omission list is longer than the feature list, and every omission says why — see Limits and scope.
  4. No scraping, ever. Official API only. Your credentials go to api.linkedin.com and nowhere else.

What it is not

It is not a growth tool, a scheduler, or an analytics dashboard. It is a small, correct program that posts and remembers — sized to what one person can actually use, running on Go with no runtime dependencies.

How it was built

The scaffold came from CLI Printing Press, which generates Go CLIs with a local store and offline search. The LinkedIn client, the history layer, credential handling, and every correction to the generated code were written by hand.

Two of those corrections are the reason this works at all: capturing the post ID from the response header, and resolving the member URN at runtime instead of accepting it as a parameter. Both were absent from the generated output. A third — that image upload has no finalize step — was caught while writing the spec.

Author

Built by Aswath AS — AI developer working across AI, Web3, finance, and security. Portfolio · Source

License

Apache-2.0. Use it, fork it, extend it. If LinkedIn opens a scope that was closed when this was written, the architecture will take it — the local history already stores what a comments table would need.