Access to the Open Data API is subject to rate limiting: if you submit too many requests within a short period of time, you will be unable to submit further requests to the API until your limit resets. This is to ensure that the API performs well for all users and that it is not possible for a single application to overload the server.
The Open Data API is configured to allow any given API key to submit up to 2000 requests per hour.
You are recommended to implement a local caching mechanism to reduce the number of requests you need to make to the server.
With the exception of the
/table endpoint, all responses from the Open Data API return
ETag header. To check whether a resource has changed,
your application can include this with subsequent requests in the
If-None-Match header. If the resource has not changed, then the Open Data
API will return a HTTP 304 Not Modified response. 304 responses do not count towards your rate limit.
Check Your Rate Limit
/rate_limit endpoint returns information about your current rate limit. In addition, all requests return the 3
allowing you to check your rate limit at any time without having to submit a specific request.
|The language that labels will be returned in (setting this is equivalent to changing the dataset and user interface language in Stat-Xplore).
|Optional. If not set, the server default language will be used.
|The API Key to use to authenticate this request. You can obtain your API key from the Account page in Stat-Xplore.
|Required in all requests.
|If you provide a known Etag value, then (if the response has not changed) this endpoint will return a 304 response instead of the response body. 304 responses do not count against your rate limit usage.
|Optional. If not set, the request will count against your rate limit usage.
|The rate limit configured for this server, this is set to 2,000.
|The number of requests remaining for the current rate limiting period. If this value drops to 0 then you will not be able to submit any further requests using this API key until the limit resets.
|The time when the rate limit will next be reset. This is expressed as a UNIX timestamp in milliseconds (the number of milliseconds since January 1st 1970).
|The checksum of the response. You can store this and use it in the
If-None-Match header in subsequent requests.
This will allow you to check whether the resource has changed without affecting your rate limit.
Following is an example response. In this example the API key has 100 requests remaining (from a configured rate limit of 2000). This allocation will be reset at UNIX timestamp 1451001600000 (25/12/2015 at midnight UTC).