Wubook API quotas in 2026 — what changed and why our modules did not need adjusting
On 18 February 2026 Wubook shipped a quiet update to their API rate limits. There was no blog post, no email, no changelog entry — the only trace is a slightly different HTTP header (X-RateLimit-Remaining) appearing on responses that previously did not have it. Here is what we know from the past three months of production traffic, and why customers on Newbookclloud did not need to lift a finger.
What used to be the ceiling
Prior to February, the documented soft limit was 60 requests per minute per authentication token, with a burst allowance of 90 sustained for up to 15 seconds. Beyond that, Wubook returned HTTP 429 with a Retry-After header suggesting a back-off. In practice, hotels running a busy channel mix during the Rome Jubilee bookings in April 2025 sometimes bumped the ceiling when Booking.com's bulk-push cascaded into per-reservation availability writes.
What changed
The new soft limit is 120 requests per minute with a burst allowance of 240. Wubook has also introduced a per-endpoint carve-out: Reservations reads are metered separately from Rates writes, which means a heavy pull for reconciliation no longer starves an autopricer push.
Wubook has also removed the Retry-After header on 429 responses — a mildly annoying regression that we compensated for with an exponential-backoff wrapper (initial 300ms, doubling to a 60s ceiling). This is the only code change we shipped as a result of the update.
Why Newbookclloud modules were fine
Our aggregate request rate per property peaks at about 12 requests per minute across all twelve modules active. Sync Sentinel at 45-second poll produces the largest sustained load: ~1.3 requests per minute per property. Autopricer runs once per night and is not a rate-limit concern. Nothing in the catalogue was ever close to the old 60-per-minute ceiling, let alone the new 120.
Practical implications for you
None. If you noticed slightly faster response times on the Housekeeping Board's status updates in March, that is Wubook's per-endpoint carve-out at work. Otherwise, nothing on your end has changed and nothing on our end required a reconnect of the Wubook Login token.
What would push you against the ceiling
Two scenarios: (a) running your own script that hammers the Wubook API in parallel with our modules — you might combine to over 120 requests per minute; (b) very large hotel groups with 20+ properties on a single authentication token (rare — most groups use per-property tokens). If either applies, get in touch and we will help split your traffic across tokens.