ResRequest API

/in , , /by
ResRequest API

ResRequest API


The purpose of this documentation is intended for a software developer who wants to integrate their system with the ResRequest application programming interface (hereafter API). The ResRequest central API allows availability and booking functionality to be accessed by a third party.

ResConnect Partner Programme and API Scope

The ResRequest API provides a wide range of functionality that supports multiple use cases across the ResRequest platform.

The ResConnect Partner Programme is a defined programme that enables approved partners to use the ResRequest API specifically for agent-driven commerce and booking workflows.

Participation in the ResConnect Partner Programme does not give unrestricted access to all API endpoints. Access is granted based on the intended use case and the role under which the integration operates within the ResRequest system.

Standard ResConnect integrations typically operate using an agent-scoped access model, aligned with how agents work within ResRequest (provided the property owner gives the access permission). This allows partners to:
  • retrieve availability and agent-specific rates
  • create, amend (with limitations), and cancel bookings
  • manage itineraries (with limitations) and booking status
This access is designed to support e-commerce, itinerary planning, and distribution use cases.
Where an integration requires access beyond the scope of the ResConnect Partner Program, separate commercial and governance terms apply. These use cases are reviewed and agreed on a case-by-case basis before such access is enabled. Integration scenarios requiring functionality beyond standard agent-scoped workflows include, but are not limited to, functionality such as:
  • broader system access
  • supplier- or portfolio-level operations
  • bulk or cross-client data access
  • workflow orchestration beyond agent execution
All ResConnect Partners are required to have appropriate agreements in place with ResRequest.
Standard ResConnect Partners participate under:
  • a technical and confidentiality NDA; and
  • the ResConnect Partner Programme agreement, which governs agent-scoped, e-commerce use of the API.

Pricing / Service Charges

ResConnect Partner Programme – Once-off Setup
Partners integrating via the ResConnect Partner Programme are required to complete an initial onboarding process, which includes sandbox provisioning, access setup, compliance coordination, and integration readiness checks. This onboarding is charged as a once-off setup fee, based on our annual rates. Please note:
  • This fee covers programme access and coordination only
  • Any technical or development assistance is not included and will be scoped, quoted, and billed separately in advance at our standard professional services rates

For 2026, this once-off setup fee is $175 / R3,000. Partners are required to provide their invoicing details before we can provision and activate the sandbox environment.

Big Data Access
Big Data API calls are designed for customers and partners who need to extract large datasets for reporting, business intelligence, or data warehousing. Because these calls place a materially higher load on our infrastructure, Big Data access is treated as an extended service and is billed separately based on our annual rates and usage tiers. Charges apply only where Big Data calls are used and are structured to remain predictable and capped at scale. Standard operational API usage remains included in the licence and partner access.

For 2026, this monthly fee is $25 per property / R450, capped at 5 properties.

Use of ResRequest API and Data

Access to the ResRequest API is granted strictly for the approved partner’s own use and for the specific integration purpose agreed with ResRequest.

Data, access or functionality made available through the ResRequest API may not be resold, redistributed, sublicensed, republished, shared or otherwise made available to another platform, service, data provider or third party without the prior written agreement of ResRequest.

In particular, an approved integration may not be used as a means of extending ResRequest data or API functionality downstream to additional systems or platforms. Any third party wishing to access or use ResRequest data or functionality must have the appropriate agreement directly in place with ResRequest.

ResRequest data accessed through the API may not be used to train, fine-tune, develop or improve any artificial intelligence, machine learning system or large language model (LLM), including the creation of derived datasets, behavioural models or similar learning systems, unless expressly agreed to in writing by ResRequest.

All integrations must operate within their approved scope of use and in accordance with the applicable partner, technical and confidentiality agreements.

Use of the API or ResRequest data outside of these agreed terms will be regarded as a breach of the applicable agreement. Where such use is identified, ResRequest reserves the right to suspend or terminate the API connection and associated access.

Development Assistance and Support

Where an integration requires technical involvement, custom development work, detailed implementation support, or architectural guidance beyond standard support, this is handled as a professional services engagement and is billed at ResRequest’s standard development support rates.

API Background

There are two basic functions which the API performs. The first is to allow for availability, rates, contact and other related information to be retrieved and the second is to allow bookings to be placed.

Availability

The availability returned is based on the access control and relationship of the login used when making an API call. All property access control, availability limits and allocations are applied as if the user was logged into ResRequest.

If any external entity such as a web portal requires use of the API, it should be added as an agent and have allocations applied.

There are two ways in which a client may elect to set up the availability for any given sales channel, namely:

  1. Use agent allocations. This is already available in the system and will allow for the channel to have exclusive access to a certain number of rooms.
  2. Use calendar limits. This is already available in the system and will allow for the risk of overbooking to be limited and availability to be shared between multiple channels but will not allow rooms to be locked for internal use.

Rates

The rates types accessible are based on the access control and relationship of the login used when making an API call.

Contacts

Contacts can be retrieved using search filters on “id”, “last name”, “first name” and “email address”.  Additionally the agent role flag or guest role flag can be specified if additional role information is required.  It is also possible to filter by guest trip related fields: accommodation type and travel dates. This function is not available to “external” users (an external user is a user setup in the principal system with an Agent relationship).

Bookings

Booking requests are made in a single call. This means that all 3 steps of the wizard are condensed into a single booking request call. The reply to this call will include the reservation number and financial information.

The status of booking requests will be subject to review in the requests received module. Any valid reservation status may be requested. It must also be possible for the status of any requests from a specific channel to either be locked to a specific status or for the status to be limited to a specific list. This requires a change to the agent role popup where two status related settings are to be added. The first is a list of all available statuses where access to each status may be set. Second is a setting to control the default status if none is specified or to lock the status.

Payments

Payments can be made through the API via the default payment gateway setup on the client.  It is therefore a requirement that this default payment gateway has been set up correctly prior to making a payment.

Internal / External users

Some functionality is only available to users set up in the principal system with a “Staff relationship”. Agents connecting to the principal will almost always be set up in the principal system with an “Agent relationship”. Some practical examples of what this means are:

  • Staff users can look up all bookings linked to all agents; whereas an Agent user can only look up bookings linked to the Agent they are related to in the principal system.
  • Staff users can be permitted to edit reservations; whereas Agent users cannot edit reservations.

A user’s relationship and permissions are determined by the principal. User permissions available via the API are replicated with the user’s manual login to the principal’s ResRequest system.

Amendments and Cancellation

The ResRequest API does not support amending or cancelling reservations. You will need to email a request with amendments or cancellations to the Reservation Office. The contact details (name and email address) of the Reservation Office and Principal can be returned with the “ac_get_default” call.

Developers can also make use of our API cancel email functions: rv_request_cancel and rv_request_cancel_itinerary to send an email to the principal requesting a cancellation. No actual cancellation is made electronically.


  • At a business level

    When the principal receives a cancellation email they may ask for cancellation fees depending on their business terms. Holding and releasing stock in high volumes can negatively impact the principal’s business and may be considered as abuse of their system by the principal. We recommend the connector partner take care when working with this function to avoid this being raised as an issue by the principal.


Unique IDs/Primary keys

We have adopted using UUIDs (universally unique identifier) as ID’s for our records. It is, for all practical purposes, unique, without depending on a central registration authority, unlike most other numbering schemes. This eliminates conflicts between data sources or database tables, and brings us in line with accepted software practices.

The change to UUIDs came into effect on version 7.x of ResRequest Enterprise.

All our old records that were created prior to version 7.x will still have the old, 11-character IDs, but all new records will have the new 36-character UUID fields – with the exception of some public-facing tables such as reservation or invoice numbers that remain unchanged.

These public-facing IDs , or primary keys in ResRequest typically take the form of , e.g. WB1, WB2, RS1, RS2 and so on. It is possible for different kinds of records in ResRequest to have the same Unique ID/Primary key. This is because they belong to different database tables and need only be unique within the table, i.e. it is possible for a property and a rate group to both have the ID “WB1”.


  • Notice

    Everyone that has developed software to interface with our API will need to update their software to accommodate the 36 character length IDs.