Policy
A policy says who may do what on which resources. It links principals to allowed actions on matching objects (and related API resources). Credentials such as API keys authenticate as a principal; policies decide what that principal is allowed to call.
An account can have many policies. Use separate policies when different identities need different rights—for example a publisher that may set state, a browser client that may only read and subscribe, or staging rules that do not apply in production. Prefer narrow patterns over "*" wherever you can, so one leaked or over-scoped key does not unlock everything.
What a policy defines#
Each policy has an id and a definition with three pattern lists:
principals
Which principal ids this rule applies to (exact ids or patterns such as *).
actions
Which operations are allowed (for example set state, get object, or *).
objects
Which object name patterns are in scope for those actions.
A request is allowed when the calling principal, the attempted action, and the target resource all match at least one policy. Broad patterns like "*" match everything in that field—review them carefully before saving.
When to use these endpoints#
- Grant access after you create a principal and before that identity needs to call the API
- Tighten or widen rights when you add apps, environments, or object namespaces
- List policies with a glob-style pattern when managing many rules
- Delete a policy you no longer need (confirm what access you are removing first)
Endpoints#
Related resources#
Policies sit between identities and the data they touch: