BYOK
BYOK is useful when you want AnyInt-level routing, governance, or observability while still using your own upstream provider credentials or commercial agreements.
BYOK is useful when you want AnyInt-level routing, governance, or observability while still using your own upstream provider credentials or commercial agreements.
Typical use cases
- existing provider contracts
- provider-specific compliance requirements
- staged migration from direct-provider access to a unified gateway
- keeping premium or regulated traffic on customer-owned upstream accounts
Decisions to make early
| Question | Why it matters |
|---|---|
| Which providers are customer-owned vs platform-owned? | This affects routing, billing, and support boundaries |
| Who rotates the upstream credentials? | Someone must own renewal and incident response |
| Can traffic mix across BYOK and non-BYOK resources? | Silent mixing causes billing and compliance confusion |
| Which teams can attach or edit BYOK credentials? | This should usually be restricted to admins |
Recommended operating model
- decide which workloads require BYOK
- keep separate keys or projects for BYOK traffic
- document who owns upstream key rotation
- make routing policy explicit so requests do not cross billing boundaries accidentally
Customer-facing expectation
BYOK should be explained as a control and sourcing model, not just as a technical toggle. The value is separation of ownership, billing, and compliance responsibility.
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.
Pay As You Go
Pay As You Go is the simplest self-serve billing model in AnyInt. You top up your account balance, create an API key, and usage is deducted directly from that balance as requests are made.