The optional MIDAS API allows developers to interface with a MIDAS booking system.
For our self-hosted customers, there are no usage limits imposed on API usage. However, for our cloud-hosted customers, we have an API "fair usage" policy in place, to help ensure quality of service for all our hosted customers.
Our "fair usage" policy applies both to the number/rate of API calls made, and the amount of data retrieved via the API.
API access may be temporarily automatically suspended for cloud-hosted customers who exceed these API limits.
If you find that your API access is frequently suspended due to exceeding usage limits, then consider the following advice:
Reduce the frequency of automated API calls
If your code makes automated calls to your MIDAS API every minute, consider reducing this to every 5 minutes.
For instance, by default, a MIDAS system is configured to allow booking to the nearest 5 minute internal. Whilst this can be changed, booking to the nearest 5 minutes is suitable in most cases.
If your MIDAS system is configured to allow booking to the nearest 5 minutes interval and you're making API calls to check whether any bookings have just started, there would be no need to do this every minute of every day, as bookings can only start at 5 minute intervals (i.e. 9.00am, 9.05am, 9.10am, etc).
Reduce the "window" of calls that accept a start/end date/time
If you're making API calls which accept a "start" and "end" parameter, such as the "get_bookings" call, consider using a narrower "window" between the start and end parameters. For example, if you're only interested in future bookings, make sure that the "start" parameter is passed with the current date/time. This will return fewer bookings (and therefore less data) that a wider encompassing start/end range.
Make use of optional parameters to "filter" and reduce the amount of data being returned
Passing one or more optional parameters with your API calls (where applicable) will further reduce the amount of data returned.
For example, passing the optional "type" parameter with a "get_bookings" API call will limit the returned bookings to those of a certain booking type, rather than returning all bookings.
Make use of the "modified_since" parameter of the "get_bookings" call
If making "get_bookings" API calls to retrieve booking data, make use of the optional "modified_since" parameter to only return details of new/changed bookings.
As an example, let's assume your code is making automated "get_bookings" API calls every 10 minutes to retrieve all bookings for the current month. If no new bookings have been added, and if no bookings have been modified, then every 5 minutes, this call will return the same (and potentially large) set of data. The optional "modified_since" parameter can drastically reduce the amount of data returned with each "get_bookings" API call. Here's how:
Let's say at midnight on a give day your code makes an initial "get_bookings" API call and return the data for all bookings for the current month. Your code would then save/store this response. Ten minutes later, your code would make the same API call, but specify a "modified_since" parameter value of midnight. This API call will then only retrieve new/modified bookings made in the past 10 minutes. At twenty minutes past midnight, your code would then make the same API call, but with "modified_since" set to ten past midnight. This will retrieve only those new/modified bookings since your last API call 10 minutes earlier.
Using the data from the initial API call at midnight and two subsequent calls (at 00:10am and 00:20am) the same data set can be constructed as if "full" get_bookings calls were made on all 3 occasions. The benefit though is significantly reduced API data usage, as rather than retrieving a large data set every 10 minutes, this is only retrieved once, with subsequent API calls only retrieving changes.
We believe our "fair usage" API policy for cloud-hosted customers is generous, and will not impact the vast majority of API users. However, if you do find that you hit API limits, the above suggestions should help you reduce your number/frequency of API calls, and the amount of data returned by each call.
If you still find that you are regularly hitting API limits and are unable to refactor your code to reduce the frequency of API requests and/or the amount of data returned by your API calls, then please contact us. We may be able to increase your limits for an additional charge.
