IP allowlists, sub-accounts and permission tiers: a survey of relay governance
Why "does it work" is not enough
Personal use needs three conditions: it connects, the price is acceptable, it is stable enough.
The moment a team or commercial use is involved, a different set of capabilities matters: who may use it, how much they used, and how to investigate when something goes wrong. That set is what we mean by "governance".
Governance cannot be established by one test call. It is a question of which features exist. So what follows is a tick-box checklist you can take and compare directly.
Dimension one: credential governance
| # | Checkpoint | Importance |
|---|---|---|
| 1 | Can create multiple keys | Required |
| 2 | Each key can carry a spending cap | Required |
| 3 | Each key can carry a model allowlist | Important |
| 4 | Each key can carry an IP allowlist | Important |
| 5 | Each key can carry an expiry date | Nice to have |
| 6 | Keys can be temporarily disabled rather than deleted | Important |
Item 6 is easily overlooked and very practical: disabling keeps the logs and is reversible, while deletion destroys the audit trail. During an incident — see our article on emergency response to a key leak — whether you can "disable first, then investigate" directly determines how fast you can respond.
Item 2 is a required one: it is the only mechanism that stops the bleeding automatically. If the site does not support it, you have to implement counting and blocking in your own code.
Dimension two: organisational governance
| # | Checkpoint | Importance |
|---|---|---|
| 7 | Supports sub-accounts with independent logins | Required for teams |
| 8 | Independent quotas between sub-accounts | Required for teams |
| 9 | Supports role separation (admin, read-only, standard) | Needed for commercial use |
| 10 | Supports quotas split by project or group | Needed for commercial use |
Sub-accounts versus multiple keys: multiple keys are just multiple credentials, while sub-accounts mean independent login and permissions. The former suits "the same people using different purposes", the latter suits "different people each using their own".
If there are no sub-accounts: fall back to multiple keys plus a naming convention (key-alice-prod) and your own record of who uses which key. That gets you basic control, minus the self-service queries and independent logins.
Dimension three: observability
| # | Checkpoint | Importance |
|---|---|---|
| 11 | Provides call logs with time, model and token counts | Required |
| 12 | Logs can be filtered by key | Required |
| 13 | Logs retained for at least 30 days | Important |
| 14 | Can view balance and consumption trends | Required |
| 15 | Supports balance alerts by email, SMS or webhook | Important |
| 16 | Has an API for querying usage, so you can aggregate it yourself | Nice to have |
Items 11 and 12 are required: without logs you have neither reconciliation nor incident investigation.
Item 16 is worth a lot. With it you can pull usage into your own reporting and build a single view across suppliers. If a site only offers a web dashboard, you are reduced to manual screenshots.
Dimension four: billing and settlement
| # | Checkpoint | Importance |
|---|---|---|
| 17 | Billing basis is stated in writing, including multiplier baseline and input/output parity | Required |
| 18 | Supports bank transfer and invoicing | Required for enterprises |
| 19 | Provides an exportable bill | Needed for enterprises |
| 20 | Balance is refundable, with clear conditions | Important |
Item 17 matters in personal use too, since without the basis you cannot reconcile. See our article on the five terms to check before topping up.
Dimension five: technical and availability
| # | Checkpoint | Importance |
|---|---|---|
| 21 | Has a status page or announcement channel | Nice to have |
| 22 | Provides an incident response commitment | Needed for commercial use |
| 23 | Supports multi-channel redundancy, so one channel failing can be routed around | Important |
| 24 | Has a technical support contact with timely responses | Important |
How to use this checklist
Layer it by purpose:
- Personal use: only items 1, 2, 11 and 14 matter.
- Small team, 3 to 10 people: 1 to 6, 7, 8, 11, 12, 14, 15, 17, 20.
- Commercial or enterprise: all of them, with 9, 10, 16, 18, 19 and 22 as additional thresholds.
Scoring: record each item as present, absent or partial for 1, 0 or 0.5, and weight by importance from the tables. A site below 60% is not suitable as a team's primary supplier.
Workarounds for missing features
Most relay sites are incomplete on governance. Missing features do not make a site unusable, because you can cover them yourself:
| Missing capability | How to cover it |
|---|---|
| No sub-accounts | Multiple keys plus a naming convention and a registry of who uses which |
| No spending caps | Counting and blocking at the application layer, with all requests through one exit point |
| No logs | Record model and usage per call on your own server |
| No balance alerts | Pull usage daily and fire your own notification past a threshold |
| No usage API | Export periodically by hand, or use the dashboard's export function |
| No IP allowlist | At least keep a fixed egress IP so problems can be located |
| No invoicing | Move to a site that invoices, or split usage across suppliers who can |
"Record call logs on your own server" is worth doing unconditionally. It depends on nothing from the site, and the moment you need to aggregate across suppliers, or explain usage to a colleague, it is the only evidence you have.
One criterion to close on
A simple test: if the site's dashboard cannot show usage split by key, it is only usable for personal use.
Because that means any team-scale use immediately degrades into "an unreadable pile of usage", and every subsequent control, optimisation and accountability step becomes impossible.
Was this useful? If you have run into something the article does not cover, tell us and we will verify it and update the text.
Related articles
Video generation behind a relay: three API shapes, four billing traps, one acceptance checklist
MCP through a relay: what works, what never will, and how to test it in ten minutes
A relay selection decision tree: working back from your scenario to a site
Logging and reconciliation: attributing token spend to the project level
Migrating suppliers gradually: replacing an API site without interrupting service
Build your own probe: twenty lines of script to monitor your API suppliers
Read on: a few of the services we list
This article does not point at a specific model family, so here are a few of the highest-scoring services we list, in case you want to read on. They are ordered by score and uptime and are not a recommendation.
See the full list in the directory, or browse by model family.