🚧 DEPRECATED - Accounting for API limits in your application

Due to the upcoming changes to the public API of OfficeRnD it will be necessary to make changes to your existing applications that utilise some of our endpoints.

❗️

Important

Starting from April the 1st, 2024 - if the $limit parameter is not included, it will automatically default to a value of 100.

We will be introducing limits to how much data can be received per request.
This will be achieved by using our pagination functionality and it will affect the following endpoints:

• members
• teams
• payments
• fees
• bookings and bookings/occurrences
• contracts
• posts
• passes
• plans

📘

Note

The default limit of these endpoints of a 100 entries cannot be exceeded.

Let's look at some examples for more clarification.
The scenario is that you have an organisation, which has 300 members and you want to GET them by using the /members endpoint.

Example of how making API calls works now

The current state of the API has no limits, if you call /members you'll get all 300 in one go.

In order to prepare for the migration, you can use /members?$limit=100 which will cause you to see only see the first 100 and the response from the API will contain a header called rnd-cursor next.
This can be used to get the next page of the members, i.e. you'll need to call /members?$next=rnd-cursor-next-value.

When you go to the second page, a new header will appear in the resopnse called rnd-cursor-prev this allows you to scroll back to the first page.

For more information on how pagination works, please see our guide here.

Example of how making API calls will work in the future

If you call /members, you'll automatically only see the first 100 and the response from the API will contain the aforementioned headers, which you can use to scroll through the data.

In other words the $limit parameter will be automatically applied to every request with a value of 100.