LinkedIn does not publish a limit, and the limit is not one number: it varies by account, by age, by action and by how the last fortnight went. You cannot look it up, so the design has to work without knowing it.
Treat 429 as information, not failure
A 429 is the only direct signal you get. Back off on it — exponentially, with a cap — and keep a counter per account rather than per process. Hammering through a 429 is the one behaviour that reliably makes things worse: the wait extends.
Queue per account, not per job
A global worker pool spreads load across your infrastructure and concentrates it on whichever account happens to be busiest. One queue per connected account, each with its own pacing, is more code and the only shape that holds up. It also makes the per-account billing model legible: the thing you queue on is the thing you pay for.
Make the work interruptible
Anything that cannot be paused halfway will eventually be killed halfway. Store progress, make each step idempotent, and let the thing resume. This is the same property that makes webhook retries harmless, which is not a coincidence — it is the same problem.
Measure what reached LinkedIn
Count accepted requests and visible results separately. When they diverge, you have learned something about the limit you could not otherwise see, and you have learned it before a customer tells you.