LinkedIn API Rate Limit
How LinkedIn’s API rate limiting works and how to design around it.
By André LugLinkedIn enforces daily throttle limits per app and per member, both resetting at midnight UTC, and returns HTTP 429 when either one is hit. The actual numbers are not public — they appear only in your app's Developer Portal Analytics tab. PostGate maps 429s to a retryable rate_limited error and retries with backoff.
LinkedIn doesn't publish a single global "X requests per minute" number the way some APIs do. It enforces throttle limits per app per day, resets them at midnight UTC, and shows the actual numbers only inside your own Developer Portal. Here's how the model works and how PostGate handles it so a scheduling burst doesn't silently fail.
Which limits apply to every call?
LinkedIn tracks an application limit — the total calls your whole app can make against an endpoint in a day — and a member limit — the calls a single member's token can drive through your app in that same day. Both reset at midnight UTC, and hitting either one returns an HTTP 429. There is no per-second or per-minute ceiling published for the Posts API specifically; it's the daily counters that matter in practice.
Where do you find the actual numbers?
LinkedIn does not publish standard throttle numbers in its docs. You see your app's actual limit and current usage in the LinkedIn Developer Portal's Analytics tab, and only for endpoints you've already called at least once that day — so a fresh app with no traffic yet won't show a number until it makes its first request. Treat this as an operational detail to monitor on the LinkedIn side of any BYO-app integration, not a constant to hardcode.
How does PostGate surface it?
When LinkedIn returns a 429, PostGate maps it to a rate_limited target error rather than a generic failure. It's marked retryable, and PostGate schedules the retry with backoff instead of hammering LinkedIn again immediately. Check GET /api/posts/{id}/logs for the attempt timeline if you need to see exactly when a target was throttled and when it recovered.
How do you stay under the limits?
- Spread bulk publishing across a queue instead of firing every post for every connected profile in the same second — see LinkedIn Scheduling API.
- Subscribe to webhooks instead of polling
GET /api/posts/{id}on a tight interval; polling reads count against the same daily budget as writes. - If you're on a bring-your-own LinkedIn app, watch the Developer Portal's Analytics tab directly rather than guessing at a number that isn't publicly documented.
Frequently asked questions
What happens when I hit the LinkedIn API rate limit?
LinkedIn returns an HTTP 429. PostGate maps that to a rate_limited target error rather than a generic failure, marks it retryable, and schedules the retry with backoff instead of hammering LinkedIn again immediately. Check GET /api/posts/{id}/logs for the attempt timeline to see exactly when a target was throttled and when it recovered.
Where can I see my LinkedIn app's actual rate limits?
In the LinkedIn Developer Portal's Analytics tab — LinkedIn does not publish standard throttle numbers in its docs. Limits show only for endpoints your app has already called at least once that day, so a fresh app with no traffic will not show a number until it makes its first request.
Does LinkedIn have a per-minute API rate limit for posting?
No published one. There is no per-second or per-minute ceiling documented for the Posts API specifically — LinkedIn enforces an application limit (total calls your whole app makes against an endpoint per day) and a member limit (calls a single member's token drives through your app that day). Both daily counters reset at midnight UTC.
How do I avoid hitting LinkedIn API rate limits?
Spread bulk publishing across a queue instead of firing every post for every connected profile in the same second, and subscribe to webhooks instead of polling post status on a tight interval — polling reads count against the same daily budget as writes. On a bring-your-own LinkedIn app, watch the Developer Portal's Analytics tab directly.
