New RON2 API using JSON

Available soon is our new RON2 API which uses RESTful JSON and below is a link to this new API method.

RON2 Developer Documentation - JSON

The following additional features are available/supported in the RON2 API

Travellers - multiple passenger names
Optional Extra Tours
Promotional Code

Note: For developers who wish to use XML or have already developed against our orgional RON API here is the same documentation but for XML. For faster response times we do recommend that Json is used.

RON2 Developer Documentation - XML

Note: This documentation and linked pages references the current RON API which uses a xmp-rpc API.

The ResPax Operator Network (RON) XML API is the window into a real-time tour operator portal network connecting in real-time to major Australian, New Zealand and Asia tour operators. The ResPax Operator Network enables development of interfaces to directly interact with each operator retrieving tour details with imagery, check availability, check prices and commit bookings directly into the remote operators system.

The RON XMLRPC API is suitable for Travel Agents, Online Agents, Inbound Agents, Online Operators and Online Portals needing to develop a direct system-to-system interface between their system and the ResPax Operators

Typical advantages include much reduced handling time for staff when dealing with a booking and much less waiting time for clients as they are interacting directly with the remote systems. Interacting directly with the Operators also means reduced training of the agents consultants. Instead of using individual booking interfaces for each operator, the agent’s consultants can now book each operator directly through their existing system which they are already trained to use.

RON also provides extensive caching of any information from the operator. The cache categorises the data depending on importance of the cache data and how often it’s changed. Each category have individual cache expiry. For example, tour content and pricing are updated every 7 days. Availability is updated every 2 hours. Any booking is placed directly into the remote systems after a live availability check has been made.

Caching is the key to interacting with multiple remote systems as remote internet connections and systems has various degrees of reliability. The caching creates a much higher availability. Most data is available directly from the cache even if the remote system is down.

Featured Pages

Search this documentation

Browser not supported