LinkedIn bans are about IP egress, not rate limits
Self-hosting an unofficial-API bridge (LinkedIn, Instagram, etc.) from a cloud VM and trying to tune away the resulting account bans.
When LinkedIn (or similar enterprise consumer platforms — Instagram, Snapchat fall in the same bucket) kills your session within minutes despite low request volume, the impulse is to look for rate_limit / throttle / delay knobs in the bridge config. There aren't any meaningful ones, because rate isn't the signal. The signal stack is: (a) cookie/session was minted from a residential IP (your laptop) but is now being used from a known datacenter IP block (AWS, Azure, GCP — they all have public ASN ranges these platforms maintain lists of); (b) the bridge's Go/Python HTTP client has a recognizable JA3/JA4 TLS fingerprint distinct from a real browser; (c) the session has no human interaction signals (mouse moves, focus events, scroll) — only API calls. Stacking those three is what triggers the cookie kill, often after a handful of requests. Changing the auth flow (cookies vs username/password) doesn't help — username/password from a datacenter IP fails the SAME detection faster (login-from-new-device challenge). What actually fixes it: route bridge traffic through a residential IP (wireguard tunnel back to your home, residential proxy SaaS, or hosted service like Beeper Cloud that pools residential IPs). Self-hosting from a known cloud VM ASN is fundamentally hostile to this class of platform.
Before spending time on a bridge for any platform with serious anti-abuse (LinkedIn, Instagram, Snapchat), check your egress IP class. curl ifconfig.me from the deploy host — if it returns an Azure/AWS/GCP IP and the platform you're bridging has consumer-grade fraud detection, expect bans within hours regardless of bridge config. Either pre-build the residential-IP egress story (wireguard / proxy / managed service) or just accept the platform stays manual.