If an inbound REST API request matches multiple rate limit rules for the same resource, rate limiting priority is enforced as follows:

• Rules set for Single user override rules for All users and rules for Users with role.
• Rules set for Users with role override rules for All users.

In this example, there are four rate limit rules for the REST API resource GET /now/v2/table/incident.

These rate limit rules are applied in the following order:

1. Limit incidents by user applies to ITIL User, who can submit up to 200 requests per hour.
2. Limit incidents by import admin applies to all users with the import_admin role. Each user with the import_admin role can submit up to 500 requests per hour.
3. Limit incidents by itil applies to all users with the itil role. Each user with the itil role can submit up to 100 requests per hour.
4. Limit incidents applies to all users. Each user can submit up to 100 requests per hour.

You can generate inbound REST API requests using the REST API Explorer or an HTTP client, such as Postman API platform. If the request matches a rate limit rule, several HTTP response headers provide information about rate limiting.

• X-RateLimit-Limit displays the number of requests allowed per hour.
• X-RateLimit-Reset displays a UNIX timestamp for the next scheduled reset of the rate limit window.
• X-RateLimit-Rule displays the sys_id of the rate limit rule [sys_rate_limit_rules] that is being enforced.

If a request is denied because it exceeds the rate limit, the system returns a Retry-After response header in addition to the response headers about rate limiting. The Retry-After response header displays the number of seconds after which you can retry the request to avoid exceeding the rate limit. The following error response is returned:

{
    "error": {
        "message": "Rate limit exceeded",
        "detail": "Rate limit of 100 requests per hour for Table API exceeded"
    },
    "status": "failure"
}