API Key Groups

One logical boundary that splits hundreds of keys by quota, models, routing, billing, risk and compliance — cleanly.

If Hydite Vtslx AO is a unified motorway for LLM APIs, API Key Groups are the administrative zones on that motorway. Every Group is its own logical boundary, and every key inside a Group inherits the same set of quotas, model whitelist, routing strategy, billing tags, logging policy and risk controls.

One sentence: Keys are identity, Groups are policy. Once you have more than a handful of keys, Groups are how you keep them coherent.

For most customers above ~100k requests/day, 90% of operational issues, 95% of compliance issues and 99% of cost-attribution issues get solved at the Group layer. That's why this is the most important feature to understand.

1. Why keys alone aren't enough#

With keys but no Groups, you eventually hit all of:

• Nobody owns the quota. All keys share one rate-limit pool — one runaway script 429s the whole company.
• Bills are unattributable. $40k spent last month, but nobody can say which product / team / customer drove it.
• Models are all-or-nothing. Either everyone can hit GPT-4o or nobody can.
• Blast radius is unbounded. A leaked key in front-end code burns the whole organisation.
• Routing strategies clash. Team A wants latency-first, Team B wants cost-first — same key pool can't satisfy both.
• Audits become archaeology. Compliance digs through a single log stream mixing finance and marketing traffic.

Groups solve all six in one shot. Each Group is a self-contained policy machine — every call going through it gets stamped with that machine's rules.

2. Mental model#

1
┌─────────────────────────┐
2
                          │      Organization       │   ← top-level entity (one per company)
3
                          └────────────┬────────────┘
4
                                       │
5
            ┌──────────────────────────┼──────────────────────────┐
6
            │                          │                          │
7
   ┌────────▼─────────┐      ┌─────────▼────────┐      ┌──────────▼─────────┐
8
   │  Group: prod      │      │ Group: staging   │      │ Group: customer-X  │
9
   │  • 100k RPM       │      │ • 1k RPM         │      │ • 500 RPM          │
10
   │  • $50k/mo budget │      │ • $500/mo budget │      │ • Customer billing │
11
   │  • All models     │      │ • Cheap models   │      │ • Anthropic only   │
12
   │  • Latency-first  │      │ • Cost-first     │      │ • White-label log  │
13
   └────────┬─────────┘      └─────────┬────────┘      └──────────┬─────────┘
14
            │                          │                          │
15
        ┌───┴───┐                  ┌───┴───┐                  ┌───┴───┐
16
        │ Keys  │                  │ Keys  │                  │ Keys  │
17
        └───────┘                  └───────┘                  └───────┘

Inheritance: Organization → Group → Key

• Quotas, whitelists, risk rules, webhooks and logging policies can be set at any layer.
• Lower layers can only tighten, not relax. If Org allows 100k RPM, Group can be at most 100k; Key at most the Group's value.
• Conflicts always resolve to the strictest layer wins.

This means security can lock down red-lines at Org, business owners tune their domain at Group, and developers do the final tuning at Key — without stepping on each other.

3. What a Group can configure#

Quotas, models, billing tags and logging are available on every tier. Custom routing YAML / custom Guardrail bundles / SIEM export are Enterprise-only — see Dedicated Instance.

4. Six real-world scenarios#

4.1 Environment isolation (most common)#

Split into dev / staging / prod Groups:

• dev — 1k RPM, $200 budget, only cheap models (GPT-4o-mini / Haiku), 7-day log retention.
• staging — 3k RPM, $1k budget, same model set as prod, 30-day retention.
• prod — 2× peak headroom, full budget, 1-year retention exported to your SIEM.

Result: dev experiments can't blow up prod's budget; prod incidents aren't muddled with developer noise.

4.2 Multi-product / multi-business-unit#

A company running SaaS, marketing landing pages, and internal BI:

1
Group: saas-app          Group: marketing       Group: internal-bi
2
RPM   60k                RPM   3k               RPM   200
3
Budget$30k                Budget$2k             Budget$300
4
Models prod-grade SLA    Models  summarisation  Models  embeddings + rerank
5
Routing latency-first    Routing cost-first     Routing  most stable single

End of month, open the dashboard's Billing → Group view: three separate cost curves, token spend and unit economics. Finance never has to file cross-product tickets again.

4.3 White-label multi-tenant (SaaS reseller)#

If you're using Hydite as an LLM platform that you resell to customers, one Group per downstream customer:

• Customer A's app calls go through customer-a Group, only see the models you've allow-listed.
• Customer B uses the same Hydite instance, but quota / billing / logging / webhooks are fully isolated.
• Invoices for each customer auto-generate per Group, with your service-fee markup applied.
• A leaked key on customer A is contained to customer A's Group — no cross-customer blast.

This is exactly how Hydite serves its own downstream PaaS customers.

4.4 Security tiers / data sensitivity#

• public-website Group — only summarisation / translation models, mandatory PII redaction, full logging.
• customer-support Group — stronger models allowed, logs land in an audit bucket retained for 7 years.
• red-team Group — jailbreak research enabled, IP-locked, extra encryption on logs.

Compliance reports are now produced per Group — no more sifting massive log streams.

4.5 Canarying a new model#

When a new model lands, spin up canary-claude-sonnet-4-5:

• Routing strategy = A/B 10%: 90% old model, 10% new.
• Quota capped at 200 RPM so the new model can't blow up cost.
• Dedicated webhook fires alert if error rate goes above 1%.
• Week later: roll the 10% pattern back into the main Group, or kill the canary Group for a clean revert.

Data stays cleanly partitioned; decisions get clean signal.

4.6 Events / hackathons / classes#

Need to hand 100 students / speakers / hackers a key:

• Create event-2025-summit Group: 7-day key TTL, $5 budget per key.
• Group total budget $500, total RPM = 100× per-key cap.
• Bulk-issue 100 keys in one click.
• After the event: disable the entire Group with one click — all 100 keys die together. Zero residue risk.

5. Five common topology recipes#

Recommended priority: slice by compliance first (regulated boundaries never cross), then by business unit, then by environment. More than 3 nesting levels and management overhead spirals.

6. Three-step quickstart#

Step 1 — create the Group#

Dashboard → Channels (API Key Groups) → Create Group:

• Name — prod-api, customer-acme, event-2025-summit …
• Tier — pick a preset (Standard / Strict / Audit) or go Custom for the full form.
• Quota — RPM, TPM, monthly budget, soft budget.
• Model whitelist — tick from the dropdown (you can include a whole vendor with one click).
• Routing strategy — pick a preset or attach a custom YAML (Enterprise).
• Alerting webhook — paste your Feishu / DingTalk / Slack / email endpoint.

You get a stable Group ID like grp_acme_prod.

Step 2 — issue keys inside the Group#

Same page → Generate Key in this Group:

• Alias — human-readable name like frontend-web.
• Expiry / TTL.
• Per-key overrides (optional) — tighter RPM or model scope.
• Tags — for cost attribution, e.g. team=growth, env=prod.

The key takes the form sk-hydite-... with Group context baked into key metadata — callers don't pass a Group ID at request time.

Step 3 — zero-code adoption#

1
client = OpenAI(
2
    api_key="sk-hydite-...",
3
    base_url="https://api.hydite.com/v1",
4
)
5
client.chat.completions.create(model="claude-sonnet-4-5", messages=[...])

No Group ID in the request. Hydite resolves it from the key and applies the Group's policy bundle automatically. To switch policy, just swap to a key from a different Group — application code never changes.

7. Operating playbook#

Moving keys#

To shift a key from dev to staging, click Move to Group in the dashboard, or call the API:

1
curl -X POST https://api.hydite.com/key/move \
2
  -H "Authorization: Bearer $ADMIN_KEY" \
3
  -d '{"key": "sk-hydite-...", "to_group": "grp_acme_staging"}'

The key string does not change — clients are oblivious. Historical usage is preserved; new calls follow the destination Group's policy.

Bulk operations#

For all keys in a Group you can:

• Disable / re-enable / rotate everything in one click
• Update default TTL or default model
• Apply tags / cost centres in bulk
• Push webhook config in bulk

Useful during reorgs, billing entity changes, annual compliance reviews.

Usage & cost attribution#

Every Group exposes its own endpoints and dashboard views:

• GET /spend/groups/{group_id} — tokens / dollars / requests
• GET /spend/groups/{group_id}/by-model — breakdown per model
• GET /spend/groups/{group_id}/by-key — top spenders
• GET /spend/groups/{group_id}/timeline — arbitrary-grain time series

Sync those into your ERP / NetSuite / Workday on a cron and finance is done with manual reconciliation forever.

Audit & compliance#

Per-Group audit streams record:

• Who edited what Group policy and when (dashboard or API)
• Who issued / revoked / moved which keys
• Which calls tripped Guardrails
• Which calls were rejected for budget / rate-limit reasons
• Which webhooks fired and which were acknowledged

That's your SOC2 / HIPAA / MLPS evidence, ready out of the box.

Emergency containment#

When something goes wrong:

• Dashboard → Group → Pause ⇒ entire Group stops responding within 5 seconds.
• Dashboard → Group → Disable + Revoke all keys ⇒ all keys permanently dead — re-issue required.
• API: POST /group/{id}/quarantine ⇒ quarantine mode: only allow-listed IPs, only read-only models, full audit forced.

8. Group vs Org vs Team vs Key#

Team controls who can do, Group controls what calls must obey — they're orthogonal. A developer can belong to "Engineering" Team, mint tightly-scoped keys in prod Group, and looser keys in dev Group — same person, two policy outcomes.

9. Anti-patterns (don't do this)#

• ❌ One Group per key. Inverts the abstraction; Groups become noise.
• ❌ Using Groups as tags only. Tags without quotas means no defence when things go wrong.
• ❌ Deeply nested Groups. More than 3 levels and audit / debug becomes a nightmare. Prefer flat names with prefixes.
• ❌ No default Group. Calls leak into default, which is functionally "no policy".
• ❌ Differentiating per key, leaving Groups empty. Means upgrades, migrations and routing changes happen key-by-key.
• ❌ One webhook for all Groups. Alert floods drown each other; incident triage falls apart.

10. Tier availability#

See Shared Edge Instance and Dedicated Instance.

Next steps#

• Deep-dive on quotas → Rate Limiting
• Branded subdomains → Custom Domains
• Ready to upgrade from a flat key list? Open Channels → New Group and you'll have your first one running in 30 minutes.