Skip to main content
Solved

/api/v3/reservation/resources/reservable — Request for offset/pagination support, field filtering, and Checkin status timeout

  • June 8, 2026
  • 4 replies
  • 54 views

Forum|alt.badge.img

Hi,

We have been working with the /api/v3/reservation/resources/reservable endpoint and would like to raise a few concerns and feature requests.

Issue 1: No pagination support

The endpoint currently only supports a limit parameter with no way to paginate through results. For use cases where there are a large number of resources, we are forced to either:

  • Set a high limit value (e.g. limit=10000), which results in very large response payloads (potentially 100MB+) that are expensive to download and hold in memory
  • Set a low limit value and miss resources beyond that limit

Request: Could you add an offset parameter (or equivalent cursor-based pagination) so we can fetch resources in smaller pages?

Example of how we'd use it:

 

GET /api/v3/reservation/resources/reservable?limit=500&offset=0&reservableStatus=Available
GET /api/v3/reservation/resources/reservable?limit=500&offset=500&reservableStatus=Available
GET /api/v3/reservation/resources/reservable?limit=500&offset=1000&reservableStatus=Available

Issue 2: No field filtering

The endpoint always returns the full resource object for every result. In some cases we only need a small subset of fields, but there is no way to request specific fields to reduce payload size.

Request: Could you add a fields or select query parameter so callers can request only the fields they need?

Issue 3: reservableStatus=Checkin causes request timeout

When querying with reservableStatus=Checkin, the request consistently times out (~30 seconds), while Available and Unavailable respond normally. Is this a known issue or a bug?

Thank you for looking into these. Pagination support in particular would significantly improve the reliability and performance of working with this endpoint at scale.

Best answer by Dawn Wayland

@vineet sharma thank you for the detailed feedback and for taking the time to outline these concerns and feature requests. I reached out to our internal teams to get clarification and wanted to share what we've learned so far.

Issue 1: Pagination Support

Pagination is already supported by this endpoint, although it is not currently documented in Swagger.

To retrieve additional pages, pass the page value returned in the previous response's nextPage property. Continue making requests until isEndOfPage is returned as true.

This pagination mechanism is supported on both GET and POST requests.

We'll work with the team to ensure this is properly documented in Swagger so it's more discoverable for all customers.

Issue 2: Field Filtering

The Reservation API is implemented as a traditional REST service and does not currently provide a field-projection mechanism (such as GraphQL-style field selection or JSON sparse fieldsets). As a result, endpoints return the complete response model for each resource.

We've logged your feedback as a feature request for future consideration as we evaluate enhancements in upcoming API versions.

Issue 3: reservableStatus=Checkin Timeout

We're continuing to investigate opportunities to improve the processing and performance of requests using reservableStatus=Checkin.

In the meantime, we recommend applying multiple filters whenever possible—such as building filters, resource type filters, and any other relevant criteria—to reduce the scope of the request. Narrowing the result set can help minimize the amount of processing required and may improve response times while we evaluate potential enhancements to the underlying query performance.

We'll continue evaluating opportunities to improve the processing and performance of these requests and will provide updates as they become available.

 

4 replies

Dawn Wayland
Forum|alt.badge.img
  • Community Manager
  • Answer
  • June 10, 2026

@vineet sharma thank you for the detailed feedback and for taking the time to outline these concerns and feature requests. I reached out to our internal teams to get clarification and wanted to share what we've learned so far.

Issue 1: Pagination Support

Pagination is already supported by this endpoint, although it is not currently documented in Swagger.

To retrieve additional pages, pass the page value returned in the previous response's nextPage property. Continue making requests until isEndOfPage is returned as true.

This pagination mechanism is supported on both GET and POST requests.

We'll work with the team to ensure this is properly documented in Swagger so it's more discoverable for all customers.

Issue 2: Field Filtering

The Reservation API is implemented as a traditional REST service and does not currently provide a field-projection mechanism (such as GraphQL-style field selection or JSON sparse fieldsets). As a result, endpoints return the complete response model for each resource.

We've logged your feedback as a feature request for future consideration as we evaluate enhancements in upcoming API versions.

Issue 3: reservableStatus=Checkin Timeout

We're continuing to investigate opportunities to improve the processing and performance of requests using reservableStatus=Checkin.

In the meantime, we recommend applying multiple filters whenever possible—such as building filters, resource type filters, and any other relevant criteria—to reduce the scope of the request. Narrowing the result set can help minimize the amount of processing required and may improve response times while we evaluate potential enhancements to the underlying query performance.

We'll continue evaluating opportunities to improve the processing and performance of these requests and will provide updates as they become available.

 


Forum|alt.badge.img
  • Author
  • New Participant
  • June 11, 2026

Hi ​@Dawn Wayland ,

Thank you for the quick and detailed response — really appreciate you reaching out to the internal team on this.

On Pagination: This is great news! We'll implement the cursor-based pagination using the nextPage property and isEndOfPage flag right away. Looking forward to seeing it documented in Swagger as well.

On Field Filtering: Understood, thank you for logging it as a feature request. We'll work with the full response for now.

On Checkin Timeout: Thank you for looking into it. We'll keep that in mind regarding applying additional filters to narrow the scope.

Feature Request: Dedicated Resource Types Endpoint

One additional request — would it be possible to add a dedicated endpoint to retrieve the list of distinct resource types directly, something like:

 

GET /api/v3/reservation/resources/types

Currently, to discover what resource types exist, we have to fetch a large number of resources and extract the distinct type and subType values ourselves. This is inefficient — we're downloading hundreds of full resource objects just to get a handful of type names.

A lightweight endpoint that returns just the available resource types would significantly reduce the overhead for this use case.

Thank you again for the support!


Dawn Wayland
Forum|alt.badge.img
  • Community Manager
  • June 11, 2026

Thanks for the suggestion.​@vineet sharma.  I agree that retrieving all resources just to derive the available type and subType values can be inefficient.

We'll add that dedicated endpoint for evaluation. 

That said, this is something our Engineering team will want to evaluate carefully. While there are clear usability and performance benefits, there are also considerations around how this type of metadata is exposed. We want to ensure that any solution is designed in the best interest of our users while maintaining appropriate security and platform design principles. Gathering feedback on this endpoint will help inform that evaluation.


Forum|alt.badge.img
  • Author
  • New Participant
  • June 12, 2026

Thank you for considering it, ​@Dawn Wayland! Really appreciate you passing it along to the Engineering team. Looking forward to hearing how the evaluation goes!