UsefulKey
Additional info

Multi-tenant patterns

Isolate keys, limits, and analytics across tenants.

Key ownership

  • Store tenantId in key metadata: { metadata: { tenantId: 't_123', ... } }.
  • Use userId for end-user association where applicable; keep tenant separate.

Namespaces for isolation

  • Use distinct rate limit namespaces per tenant, e.g. tenant:<id>.
await uk.verifyKey({ key, identifier: req.ip, namespace: `tenant:${tenantId}` });

This ensures counters and token buckets do not cross tenants.

Scopes per tenant

  • With the permissions/scopes plugin, include tenant-scoped scopes (e.g., tenant:t_123:read).
  • Alternatively, keep a simple scopes: string[] and validate tenant equality in your API layer.

Analytics partitioning

  • Include tenantId in analytics payloads you emit from your app, or encode it in identifier/namespace.
  • Downstream sinks (e.g., ClickHouse) can then shard or filter by tenant.

Storage layout

  • Single table with tenant columns is sufficient; add an index on (tenantId, key_hash) in custom adapters.
  • For strict isolation, use separate databases per tenant and configure distinct adapters per instance.

Known issues

Current limitations, symptoms, and workarounds. This list will grow over time.

Roadmap

The long term goals for UsefulKey.