LinkedIn Scheduling API: Versions, Scopes, Hard Limits

LinkedIn’s Posts API has no scheduling primitive. Nothing in the request takes a future timestamp, and PUBLISHED is the only lifecycle state the schema accepts at creation, so the calendar lives in whatever system you build around POST /rest/posts. What decides whether that system survives a client campaign is rarely the copy. It is the app tier you were granted and the version header you pinned months ago. The quota resets at midnight UTC whether or not your queue is empty.

Developer runbook: one endpoint and a version string with an expiry date.

In short

• POST /rest/posts publishes now. A scheduler stores its own timestamp and calls the endpoint at that minute.
• Member posting is self-serve. Company Page posting needs Community Management, a vetted app, and a Page role the API cannot grant.
• Pin LinkedIn-Version: 202610 and store x-restli-id from every 201. Budget calls before posts.

LinkedIn has no scheduling field, so the queue is yours

The Posts API cannot schedule a post. POST /rest/posts has no scheduling parameter, and the schema accepts PUBLISHED as the only state at creation, so a scheduler holds the future time in its own store and calls the endpoint when that time arrives. Everything a marketer calls scheduling is your database and your worker.

That surprises people who use the LinkedIn UI, which schedules a profile from 10 minutes to 3 months ahead and a Page from 1 hour to 3 months, converting the device time zone to UTC. Page scheduling there also refuses events, multiple photos, reshares, polls, job posts and service posts. None of that surface exists in the Posts API. The UI schedule is a LinkedIn feature; the API schedule is your feature.

A stored job needs a timezone-aware timestamp, an author URN, an immutable payload, and a state machine that keeps queued separate from accepted and accepted separate from published. PostSider’s LinkedIn scheduler exists because that gap breaks client work: a row that says scheduled is a promise your system made, not one LinkedIn kept.

The create request itself is small:

POST https://api.linkedin.com/rest/posts
X-Restli-Protocol-Version: 2.0.0
LinkedIn-Version: 202610

{
  "author": "urn:li:organization:1234567",
  "commentary": "Shipping the queue today.",
  "visibility": "PUBLIC",
  "distribution": { "feedDistribution": "MAIN_FEED" },
  "lifecycleState": "PUBLISHED"
}

Swap urn:li:organization:1234567 for urn:li:person:{id} and the same endpoint posts as a member. That one field decides which permission model applies.

The version header expires on a date you did not choose

Every versioned LinkedIn call must name its version in a LinkedIn-Version: YYYYMM header, and the latest version is not applied by default. Omit the header and the call returns an error rather than falling back to current behavior. Each version is supported for at least a year.

At the time of writing the current version is 202610. Version 202510 was already sunset on 15 October 2026, and 202511 sunsets on 16 November 2026. If the string lives in three config files and nobody owns it, the integration breaks on a date somebody else picked. Keep it in one place, log it with every job, and put the anniversary in a calendar 60 days ahead. The failure is quiet: a queue that runs all night and leaves errors in a log nobody reads.

X-Restli-Protocol-Version: 2.0.0 is the other header, and it moves on a slower schedule.

A company Page post requires a vetted app before it requires copy

Share on LinkedIn is the self-serve product and grants w_member_social for posting as an authenticated member. Community Management grants member and organization posting, and it is limited to registered legal organizations with commercial use cases. The tier decides what client work you can attempt.

	Share on LinkedIn	Community Management
Who grants it	LinkedIn, self-serve for any developer	LinkedIn, after review of a registered organization
Scopes	w_member_social	w_member_social, w_organization_social, r_organization_social
Vetting	Self-serve	App verification by a Page super admin; Standard tier review asks for test credentials and a screencast
Published limits	150 posts per member per day; 100,000 per app per day	Development tier 500 calls per app per 24 hours and 100 per member; Standard tier limits are not published
Page posting	No	Yes, where the authorizing member holds an accepted Page role

The consequence lands on scheduling. You cannot promise a client a Page launch date while their app is unverified, because approval is not a form you fill in at the end of a sprint. Ask about the tier and the verification status in the sales call, then put review lead time into the plan before the content calendar is signed.

Page roles are granted in the UI and read from the API

LinkedIn does not allow Page roles to be granted or updated through the API. The member who authorizes a Page post must already hold ADMINISTRATOR, CONTENT_ADMIN or DIRECT_SPONSORED_CONTENT_POSTER on that organization. A scheduler can only discover what it has been given.

That makes onboarding a two-party job. Someone at the client adds your authorizing member to the Page before the token exchange. The Page selector in PostSider lists organizations where LinkedIn returns an ADMINISTRATOR role, which is a narrower set than the Pages named in a kickoff call. If a role is downgraded later, the connection degrades before the token does, and the first symptom is a 403 on a post that worked last week.

Format ceilings decide the payload before the copy does

A LinkedIn post tops out at 3,000 characters, and the API is no more forgiving than the composer. Media is where payloads fail, because ceilings depend on asset type and some limits are invisible in the dashboard.

Format	Ceiling
Text	3,000 characters per post
Single image	Under 36,152,320 pixels; JPG, GIF or PNG; GIF up to 250 frames
Multi-image	2 to 20 images in one post
Video	3 seconds to 30 minutes; 75 KB to 500 MB; MP4
Document	Up to 100 MB and 300 pages; PPT, PPTX, DOC, DOCX or PDF
Organic carousel	Not supported by the Posts API

The organic carousel in the LinkedIn UI has no API equivalent. If a client asks for swipeable cards, the closest supported object is a document post that renders as pages. PostSider’s image-carousel option does exactly that, turning two or more images into a PDF document rather than a native multi-image post. It looks similar in the feed, so say which object you are shipping before the design is approved.

One more trap: the Posts API does not scrape a URL for a preview, so title, description and thumbnail have to be sent explicitly. Mentions use the little format @[Name](urn:li:person:123) and have to be built before the count is final. Character limits on every network covers how that count behaves elsewhere.

Tokens and rate limits cut the calendar short

Access tokens last 60 days by default, and programmatic refresh tokens last a year. When the refresh token expires the member reauthorizes, and programmatic refresh is limited to approved Marketing Developer Platform partners. A queue that assumes perpetual access stops mid-month with a 401 that looks like a code bug.

Rate limits are tighter on the Page side. Share on LinkedIn allows 150 posts per member per day and 100,000 per app per day. The Community Management Development tier allows 500 API calls per app per 24 hours and 100 per member, and the unit is calls, not posts. Standard tier limits are not published. Breaches return 429 and reset at midnight UTC.

Illustrative example, not a benchmark: an agency with 60 client Pages posting four times a day has 240 posts to publish. At two calls per post, one to register media and one to create the post, that is 480 calls before a single retry or status check. The Development tier’s 500-call ceiling is effectively reached on that schedule, and any queue that polls for status in a loop crosses it before lunch. Count calls per post in the design document, not in the incident review.

If you are weighing build against rent, the social media scheduler API comparison covers the trade.

A retry must not become a second post

A successful create returns 201 with an x-restli-id header. Persist that value and use it as the post identity, so a create that timed out can be checked instead of repeated. The dangerous case is an unknown outcome: the connection dropped after LinkedIn accepted the write.

Store the ID in the same transaction that moves the job state. On a retry, look up the stored ID before deciding the work is done. The idempotent retries for social publishing pattern applies here without modification. When a job keeps failing after a bounded number of attempts, the publishing error troubleshooting guide separates codes worth acting on from ones worth waiting out.

Data retention limits what the queue may remember

Member social activity data can be stored for 48 hours, most member profile data for 24 hours, and Community Management data cannot power a social feed use case. Those limits read like cache guidance and behave like product constraints.

The safe reading is that a queue stores what it needs to publish and verify, and nothing that resembles a history of member activity. A client who asks for a team feed of everything published last quarter is asking for a product that Community Management data is not licensed to power. That request needs a design review before it needs a database.

The pre-launch list is short and none of it is optional

These six checks catch the failures that surface once real client Pages are connected.

1. Version pinned in one config entry, with the sunset date in your calendar 60 days before the anniversary.
2. App tier and verification status confirmed in writing, and the Page role verified before the token exchange.
3. Token refresh owner named, with a reauthorization reminder a week before day 60.
4. Daily call budget written down per Page, with room for retries and status reads.
5. x-restli-id persisted on every 201, and the published URL read back after the scheduled time.
6. A human path for failures, because a scheduled item in your queue is not proof that LinkedIn accepted it.

Lukasz builds PostSider, which supports LinkedIn profiles and company Pages.