OwnerRez puts a 1,000 call limit on each API token, and offset paging dies on 5 January

If anything plugs into your OwnerRez account through the API, a pricing tool, an accounting sync, a reporting dashboard or something your own developer built, two dates belong in the diary. OwnerRez emailed app owners and personal access token holders on 21 October with both.

3 November: a limit per token, not just per address

From Tuesday 3 November 2026 at 15:00 UTC, each access token may make 1,000 API requests in any five minute window. A token here means an app's connection to one account, or a personal access token. The limit follows the token wherever the calls come from, so spreading requests across servers no longer gets around it.

This sits on top of the per address limit OwnerRez already runs, which its own documentation puts at 300 requests every five minutes per IP. Go over either one and requests come back 429 with a Retry-After header saying how many seconds to wait.

OwnerRez put a number on how many integrations this will actually bite. In the week of 1 to 8 October, 11 of roughly 11,000 active tokens went over 1,000 requests inside about five minutes. So the limit is aimed at a handful of noisy integrations rather than at normal use. If yours is one of the eleven, you will find out on 3 November.

5 January: three things that fail quietly today start returning errors

The bigger change lands in the new year. From Tuesday 5 January 2027 at 15:00 UTC, API v2 list endpoints stop accepting an offset above 0. Ask for one and you get a 400 with the code offset_not_supported.

Paging moves to cursors instead. Bookings, deposits, fees, guests, inquiries, messages, payments, quotes, refunds and reviews already return a next_page_url, and OwnerRez says every other list will by 16 November 2026. The pattern is to request the first page with no offset, then follow next_page_url exactly as it comes back until it is null. OwnerRez's reason for preferring this to page numbers is worth repeating: a cursor walk stops returning duplicate or missing rows when records are added or deleted while you are paging.

Two other kinds of request start failing on the same date. Unknown query parameters return 400 with unknown_parameter. Cursors that OwnerRez did not issue, or that are sent with different filters from the request that produced them, return 400 with invalid_cursor. Filters, for this purpose, means every query parameter except cursor, limit and offset.

The part worth reading twice

What makes this more than developer housekeeping is what those requests do today. They do not fail. They return something.

OwnerRez gives two examples. On /v2/spotrates, sending property_id instead of property_ids returns every property's rate overrides rather than one property's. And page=2 returns the first page again.

Read that again if you run reports off the API. A typo in a parameter name has been handing back the wrong data set, silently, for as long as the integration has existed. Anyone pulling spot rates with the singular parameter has been reading a different number from the one they thought they asked for. The January change is what will finally surface it.

Request bodies are not checked, so this covers query parameters only.

Three dress rehearsals

Before the cutover, all three behaviours switch on temporarily during three scheduled brownouts:

• Tuesday 17 November 2026, 15:00 to 16:00 UTC
• Tuesday 1 December 2026, 15:00 to 19:00 UTC
• Tuesday 8 December 2026, 15:00 UTC to Wednesday 9 December 2026, 15:00 UTC

That is a free test. If your integrations run through all three untouched, you are done. If something breaks during the one hour window in November, you have seven weeks to fix it rather than finding out on a Tuesday afternoon in January.

What to do

If you did not build the integration yourself, forward the dates to whoever did, or to the vendor. The question to ask is short. Does it send an offset above 0, does it send any parameter the endpoint does not document, and does it follow next_page_url exactly as returned. Three noes mean nothing changes for you.

OwnerRez is taking questions at [email protected].