Team Keys
Team keys are where AnyInt starts to behave like an operating platform instead of only an API relay. They let organizations separate ownership, usage, and policy by project or workload.
Team keys are where AnyInt starts to behave like an operating platform instead of only an API relay. They let organizations separate ownership, usage, and policy by project or workload.
Why teams use multiple keys
- separate production from staging
- isolate one project from another
- assign cost ownership by team
- keep premium models behind a narrower access boundary
Typical key metadata
The enterprise product plan treats each key as an object with:
- a name
- an optional description
- optional tags
- a creator
- a status such as
ActiveorDisabled
Key-level controls
| Control | What it does |
|---|---|
| model allowlist or blocklist | limits which models the key may call |
| spend limits | caps total usage or triggers warnings |
| rate limits | constrains RPM, RPH, RPD, TPM, or TPD |
| IP allowlists | restricts which networks may use the key |
| routing policy | defines which models or routing groups the key can use |
Practical ownership model
- Admin defines the global policy boundary
- Project Owner manages the keys inside the project they own
- Member uses keys inside the permissions granted to them
Recommended lifecycle
- create one key per environment or workload
- add a clear name and tags
- apply limits before broad rollout
- disable or rotate the key when ownership changes
Related pages
API Keys
API keys are the main way applications authenticate to AnyInt. Treat every key as a production secret, even if it only targets a low-cost or development environment.
BYOK
BYOK is useful when you want AnyInt-level routing, governance, or observability while still using your own upstream provider credentials or commercial agreements.