SLA Tiers For API Groups
As a Group Administrator, you can specify service-level agreement (SLA) tiers for API Groups instances to limit the number of requests an application (user) can make to the APIs in an API Group. SLAs enable you to protect your API Group instances and help manage network traffic to your APIs.
The SLA tier definition also determines whether access to the API Groups instance requires your approval. You can configure manual or automatic approvals to requests.
The default limit applies to all API instances. This means that the same SLA limit is applicable to every API instance in that API Group.
If you add a new API instance to an API Group instance, the default limit SLA configured at the group instance level applies, unless an individual API SLA tier is also configured by the Group Administrator.
As a Group Administrator, you can define individual limits for API instances within an API Group instance. If you have configured a default SLA limit at the API Group instance level and an individual SLA limit at the API instance level, the individual SLA overrides the default limit.
If no individual SLA is configured, then the default SLA limit is enforced for that API instance.
If the Rate Limiting policy is applied on an API instance, as a Group Administrator you must determine if the new SLA can be fulfilled by the underlying API instance.
When you configure automatic approvals for an SLA tier, requests made to the API instances with that tier applied are automatically approved. Consumers can instantaneously use API Group instances in this case.
Manual approvals are routed through a manual approval flow, where the API Group owner must manually approve the consumer request.
API Groups supports multiple SLA limits. You can set multiple throughput limits for a single SLA tier. A single SLA tier named
Premium can limit requests to 100 per second as well as limiting requests to 10,000 per day.
This strategy ensures that applications registered on a
Premium tier do not exceed the top limit of 100 requests per second. This way, applications do not inundate the API, and registered applications get the expected 10,000 requests per day.