Skip to main content
Skip table of contents

Rate Limit

Access to the Open Data API is typically 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 system administrator can choose to set different limits for the /schema and /table endpoints, and can choose to turn off rate limiting entirely (although this is not recommended). By default, the Open Data API is configured to allow any given API key to submit up to 100 table requests per hour, but a different limit may have been set on your system.

Caching

You are recommended to cache the database schema locally to reduce the number of requests you need to make to the server. There is also a server-side cache. See Configure the Cache for more details.

All responses from the Open Data API (except the /table endpoint) return an 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 304 Not Modified response. 304 responses do not count towards your rate limit.

See Use Entity Tags to Check for Schema Updates for more details.

Check Your Rate Limit

The /rate_limit endpoint returns information about your current rate limit.

There are three limits: a global setting, as well as individual settings for the /schema endpoint and the /table endpoint. Use the endpoints /rate_limit/rate_limit_schema, and /rate_limit_table to check each individual limit.

In addition, if rate limiting is configured, all requests return the relevant X-RateLimit headers, allowing you to check your rate limit at any time without having to submit a specific request.

Overview

Endpoint
https://<server>/webapi/rest/v1/rate_limit
https://<server>/webapi/rest/v1/rate_limit_schema
https://<server>/webapi/rest/v1/rate_limit_table
HTTP MethodGET

Request Headers

Accept-Language
The language that labels will be returned in (setting this is equivalent to changing the dataset and user interface language in SuperWEB2).Optional. If not set, the server default language will be used.
APIKey
The API Key to use to authenticate this request. You can obtain your API key from the Account page in SuperWEB2.Required in all requests.

Response Headers

X-RateLimit
X-RateLimit-Schema
X-RateLimit-Table

The global, schema, and table rate limits (if configured).

The individual headers are only returned if the corresponding rate limit has been set. If none of these headers are returned then that indicates that no rate limiting applies.

X-RateLimit-Remaining
X-RateLimit-Remaining-Schema
X-RateLimit-Remaining-Table

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 individual headers are only returned if the corresponding rate limit has been set. If none of these headers are returned then that indicates that no rate limiting applies.

X-RateLimit-Reset
X-RateLimit-Reset-Schema
X-RateLimit-Reset-Table

The time when the rate limit will next be reset. This is expressed as a UNIX timestamp in milliseconds (milliseconds since January 1st 1970).

The individual headers are only returned if the corresponding rate limit has been set. If none of these headers are returned then that indicates that no rate limiting applies.

Response Body

Following is an example response. In this example the API key has 100 requests remaining (from a configured rate limit of 100). This allocation will be reset at UNIX timestamp 1451001600000 (25/12/2015 at midnight UTC).

CODE
{
  "limit": 100,
  "remaining": 100,
  "reset": 1451001600000
}
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.