Defining SLA Tiers
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 as API Versions Owner or as a member of the Organization Administrators role. 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, and possess the permission or role to perform API management tasks.
You can monitor SLA performance to ensure that your APIs are performing in line with the SLA tier approved for an API.
The tutorial for adding an SLA tier describes how to define an SLA tier. To define a new SLA tier for the API version, go to the API version details page, click the SLA Tiers tab, then click Add SLA Tier. Fill in the fields to configure the tier, giving it a Name, defining the Throughput by indicating the number of requests per time period that are allowed, and then indicating whether application access requests at this tier level should be automatically approved or require manual approval. Click Submit to save the tier.
On the SLA tiers tab 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.
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.
Multiple throughput limits can be specified for a single SLA tier. A single SLA tier named gold could offer a limit of 100 requests per second as well as a limit of 10,000 requests per day. This would ensure that applications registered on a gold tier don’t exceed a bursting limit of 100 request per second. Applications cannot overwhelm the API, while registered applications are assured the advertised SLA of 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.
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 will inform about the 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.
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 the Anypoint Platform can identify them, associate them with their contracted tier, and enforce the throughput limitation.
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.
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 Applications tab of 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.
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:
Create a new tier and notify application owners of the new tier name that you create.
Revoke application access to the existing, deprecated tier.
Ask the application owners to re-request access to the API using the new tier.
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.