Page cover

Account & API Key Management

The Acceso Dashboard is the control plane for your account. It exposes configuration without exposing internal infrastructure.

The dashboard is a management interface. It is not a data execution layer. Dashboard actions map to secured backend APIs.

Account model (what you manage)

The dashboard manages account-level settings. It also manages API keys as the access primitive.

Most controls are enforced server-side. UI state mirrors backend configuration.

API key lifecycle management

Users can create, rotate, and revoke API keys in the dashboard. Each key can be labeled and scoped. Use that to separate environments and blast radius.

Recommended patterns:

  • One key per environment (dev, staging, prod).

  • One key per service, not per engineer.

  • Use labels that match your deployment units.

Core operations:

  • Key generation with tier-based defaults.

  • Manual revocation and rotation.

  • Usage visibility per key.

Keys are never displayed again after creation. This reduces exposure risk.

Key material handling (deep dive)
  • Plaintext keys are shown once at creation time.

  • Plaintext keys should not be persisted or logged.

  • Backend storage should retain only hashed key material.

  • Telemetry should record only a short fingerprint for correlation.

Key creation semantics

Key generation uses tier-based defaults. Those defaults come from backend configuration.

Common defaults include:

  • Enabled API domains.

  • Rate limits and quotas.

  • Feature flags for staged rollouts.

Rotation (staged, no downtime)

Rotation should be staged. Keep old and new keys active temporarily.

1

Create a new key

Name it for environment and service. Store it once.

2

Deploy the new key

Roll it out through your deployment system. Avoid manual handling outside secure tooling.

3

Validate traffic

Confirm requests succeed with the new key. Check per-key usage visibility.

4

Revoke the old key

Revoke only after migration completes. Treat revocation as irreversible.

Revocation behavior

Revoked keys fail authentication at request entry. No domain work should run for revoked keys.

Operational expectations:

  • Immediate enforcement on new requests.

  • Structured auth errors.

  • Non-sensitive telemetry for correlation.

Plan & feature visibility

The dashboard reflects the active plan on the account. It shows what the backend will enforce.

You can see:

  • Enabled API domains.

  • Rate limits and quotas.

  • Access to premium infrastructure features.

Feature availability is derived from backend configuration. It is not hardcoded UI logic.

Implementation notes (for operators)
  • Enforcement is evaluated server-side at request entry.

  • The UI renders from returned capabilities and limits.

  • Plan changes propagate without UI redeploys.

Last updated