Reference
Limits and scope
The list of things this can't do is longer than the list of things it can. That's deliberate, and every omission has a reason.
The rate limit
150 requests per day, per member. One post is one request. Nothing you do through postiee is pooled with anyone else's — the budget is yours alone.
search and history are local and cost nothing
against it. Posting is what spends the budget, and a loop will spend all of
it in seconds. When you run out, the failure looks like an unrelated error
rather than a limit, so check this first when a script breaks without a
clear reason.
Token life
Access tokens last 60 days. Refreshing them automatically
is reserved for LinkedIn partners, so you re-run auth login.
If you're still signed in, the consent screen is skipped and it takes
seconds.
Deleting your own post is not on this list. unpublish deletes it on LinkedIn, using the same self-serve
w_member_social scope that posting already needs. Only
reading posts back requires the closed
r_member_social. See
Commands.
What postiee can't do
| Capability | Status |
|---|---|
| Comments | partner approval Needs the Community Management API. |
| Reactions and likes | partner approval Same. |
| Analytics — impressions, followers, profile views | partner approval Separate member analytics scopes. |
| Reading your own posts back | closed r_member_social isn't accepting requests. |
| Reading who reacted to a post | closed Reaction identities are never returned to a member app. |
| Messaging and DMs | no API exists No endpoint in the docs. Mass messaging is an explicit prohibited use. |
| Connection invitations | no API exists Same. |
| Looking up another member's profile | no API exists Person IDs are app-scoped, so there's no way to resolve someone else's. |
| Running ads | separate product The Marketing API is a different platform with its own approval. |
| Scheduled posts | client-side only No publishAt field exists. Scheduling means a local timer. |
| Multi-image and video posts | partner approval One image works self-serve. post --image takes exactly one, and there is no flag for more. |
Why so many omissions
LinkedIn's API is not built for individuals posting to their own feed. It is built for marketing platforms managing thousands of company pages. So the surface that would actually help you — reading your posts, reacting to them, seeing how they performed — is exactly the surface that requires becoming a vetted partner.
A comment command that 403s on first use teaches you nothing and
wastes your afternoon. An absent command tells you the truth immediately. So
the tool ships only what works, and this page says why the rest is out of
reach.
If LinkedIn ever opens one of these, the architecture will take it. The local history already stores what a comments table would need — the post URN is the join key.
What is guaranteed to keep working
These are pinned by tests in the repository, so a change that breaks one fails the build rather than quietly changing behaviour.
| Property | Status |
|---|---|
Porter stemming — authentic finds authentication | pass |
| Multi-term AND narrows rather than widens | pass |
| An absent term returns nothing | pass |
Junk input never errors — ", AND, (), NEAR(a b), -- | pass |
| Re-recording a post upserts instead of duplicating | pass |
| Deleting removes the search index entry too | pass |
Deleting on LinkedIn sends X-RestLi-Method: DELETE | pass |
| Deleting an already-deleted post is accepted, not an error | pass |
| Post ID read from the response header, not the body | pass |
| Image upload performs exactly two calls | pass |
| URNs in paths are fully percent-encoded | pass |
Run go test ./... to confirm them yourself.
Partial-word prefix search does not work, and is not going
to. SQLite FTS5 indexes whole tokens, so
search harn misses harness. It is called out here
because a limit you know about is cheaper than one you find at 2am — not
because it is queued for support.