Policies are grouped by 3 scopes:

1. API scope

Applied at the API level.

  • Affects all operations and environments within the API
  • Useful for broad rules like authentication or rate limiting

2. Environment scope

Applied to a specific environment.

  • Choose between Dev, Staging, or Live
  • Tailor behaviour based on where the API is deployed
  • Ideal for testing or staging-specific configurations

3. Operation scope

  • Applied to a specific operation within an API.
  • For example, a policy on the GET method only affects data retrieval
  • Useful for fine-tuning behaviour at the endpoint level

Policies can be layered and inherited across scopes, giving you flexibility to manage APIs securely and efficiently.

Apply policies across different scopes

You can combine policies to create complex scopes that control how a published API behaves. These scopes can be:

  • Broad – applying across all environments or multiple APIs
  • Narrow – targeting a specific API, a single environment, or an individual operation

For example, you can set up a policy that applies only to:

  • A single API
  • All environments
  • A specific operation in an API

This flexibility allows you to tailor API behaviour to suit different use cases, environments, and audiences.

Using policies when publishing your API

Policies are optional when publishing an API. You can choose to:

  • Add policies at different scopes (API, environment, or operation)
  • Apply them across one or more environments
  • Publish your API without any policies, if needed

How policy inheritance works

Policies follow a hierarchical structure, meaning each scope inherits from the one above:

  • Operation scope inherits from the Environment scope
  • Environment scope inherits from the API scope

This allows you to apply broad rules at the API level and refine them at environment or operation level as needed.