Contact Us 1-800-596-4880
  1. Homepage
  2. API Manager (1.x)
  3. About Using Policies

  4. SLA Tiers Reference

SLA Tiers Reference

A Service Level Access (SLA) tier is a category of user access that you define for an API. The tier definition combined with an SLA-based policy determines whether access to the API at a certain level requires your approval. The tier definition also can limit the number of requests an application can make to the API. To enforce SLA tiers, you need to apply a rate-limiting or throttling policy that is SLA-based.

To define SLA tiers for an API version or to manage applications that request access to specific tiers, you need to set the API URL.

You can monitor SLA performance to ensure that your APIs are performing in line with the SLA tier approved for an API.

Defining a Tier

When you define a tier, you name the tier and define limits, such as the number of requests calling apps can make. You also indicate whether application access requests at this tier level should be automatically approved or require manual approval.

On SLA Tiers on the API version details page, a summary of the SLA tier definition appears showing how many applications are registered on that tier and other information, tier name, limits, status, and required approval type.

You can edit and delete the tier using the provided controls.

Layered SLAs

Multiple SLA limits are supported under the following conditions:

  • API Manager manages the API.

  • API Gateway runtime 2.1 or later manages the API.

API Gateway runtime 2.0 and earlier does not support multiple SLA limits. API Manager enforces only the first layered SLA tier if you define multiple limits on API Gateway Runtime 2.0 and earlier.

You can set multiple throughput limits for a single SLA tier. A single SLA tier named gold can limit requests to 100 per second as well as limiting requests to 10,000 per day. This technique ensures that applications registered on a gold tier don’t exceed a bursting limit of 100 requests per second. Applications do not overwhelm the API, and registered applications get the expected 10,000 request per day. Setting the Visible flag on an SLA hides the first limit from application developers at registration time. If you define only one limit, you cannot hide it.

Response Headers

Three headers are included in request responses that inform users about the SLA restrictions and the remaining spare capacity that the SLA allows. When this SLA enforces multiple policies that limit request throughput, a single set of headers reports spare capacity in reference to only the most restrictive of the policies in place.

For example, a user of your API may receive a response that includes these headers:

X-RateLimit-Limit: 20
X-RateLimit-Remaining: 14
X-RateLimit-Reset: 19100

In this case, the response tells users that within the next 19100 milliseconds, only 14 more requests are allowed by the SLA, which is set to allow 20 within this time-window.

Enforcing a Tier

To enforce SLA tiers, you need to apply a rate-limiting or throttling policy that is SLA-based. These policies require all applications that consume the API to register for access to a specific tier, then pass their client credentials in calls to the API, so that Anypoint Platform can identify them, associate them with their contracted tier, and enforce the throughput limitation.

Editing a Tier

If you edit a tier that already has applications approved to use that tier, those applications are immediately held to the terms of the edited tier. Thus, if you change the throughput values without warning, you might inconvenience API users.

If you originally set the tier to require manual approval, and change it to allow automatic approvals, API Manager grants any pending approval requests.

Managing Applications

After you define an SLA for an API, you can approve or revoke access requests from app developers through the Developer Portal. This action binds consumption of the application to an SLA. If a developer requests access to your API at a higher SLA tier than you want to approve, you can override the request by applying another SLA tier.

If you set the tiers for manual approval, email notifications are sent to you when developers request access for their applications. You can review the applications on the API version details page and approve, reject, or revoke requests. If a developer asks to change tiers, you can also review the change request and approve the application for the new tier or reject the change request.

Deprecating and Deleting Tiers

After you assign applications to SLA tiers, you have the option to deprecate a tier to prevent developers from signing up new applications up for that tier. You cannot delete an SLA tier that has applications assigned to it.

To deprecate and delete a tier, first create a new tier and notify application owners of the new tier name that you create. Next, revoke application access to the existing, deprecated tier. Ask the application owners to re-request access to the API using the new tier. Finally, after all application owners sign up for a new tier and you approve their move to the new tier, you can delete the deprecated tier.

See Also