API rate limit

A cap on how many requests a connected system may make to a PMS API in a given window of time. Go over it and the API stops answering, returning an HTTP 429 response, usually with a Retry-After header saying how long to wait before trying again.

Limits are set in one of two ways, and the difference decides who it affects.

Per IP address. Counted against the server the requests come from. An integration running on several servers spreads its traffic across several limits.

Per token. Counted against the credential, meaning an app's connection to one account or a personal access token, wherever the calls originate. Spreading across servers no longer helps.

Vendors are moving towards per token limits because they target the one noisy integration rather than everyone sharing an address.

Operators rarely hit a limit themselves. The systems that do are the ones plugged into the PMS: pricing tools, accounting syncs, reporting dashboards and AI assistants. If one of those starts missing data or falling behind after a vendor changes its limits, rate limiting is worth ruling out before anything else. The usual fixes sit with the integration, not with you: queue incoming webhooks and process them in the background, and keep a local copy of the data rather than re-querying the API for every event.