Skip to main content
Renamed 2026-05-03. This feature was previously called Databases. The old /v1/databases/* and /admin/databases/* paths now return 404 — use /v1/dyn-db-credentials/* and /admin/dyn-db-credentials/*. The “Databases” name has been freed for the upcoming Database Proxy product (a TCP-level Postgres / MySQL wire-protocol proxy — see the Dynamic Credentials & Protocol Proxies design doc for context).

Dynamic DB Credentials overview

KnoxCall’s Dynamic DB Credentials feature lets you mint short-lived database credentials on demand — for engineers, CI pipelines, scheduled jobs, or any workload that needs temporary DB access without sharing a long-lived password. You register a database connection once. After that, callers ask KnoxCall for a credential whenever they need one. KnoxCall mints a fresh username + password (or an AWS auth token), tracks it as a lease, and automatically revokes it at expiry.

Why use it

How it works

  1. Register a connection — point KnoxCall at your database (Postgres, MySQL, or MongoDB). Pick one of four authentication modes.
  2. Define a role — an SQL template that describes the kind of user to mint (read-only, read-write, or your own template). Built-in readonly / readwrite templates work for most setups.
  3. Mint a credential — call POST /v1/dyn-db-credentials/{name}/creds/{role} with an API key. Get back a username + password + expiry.
  4. Use it — connect with the returned credentials like any other DB user.
  5. Forget it — at the lease’s expiry, KnoxCall drops the user automatically. Or revoke it explicitly with POST /v1/dyn-db-credentials/leases/{id}/revoke.

Quick start (UI)

  1. Go to Dynamic DB Credentials in the admin UI and click New Connection.
  2. Fill in the connection details. Test the connection — KnoxCall verifies it can reach your DB before letting you save.
  3. After creation, expand the connection and click Register role → pick readonly or readwrite.
  4. Click Mint credential to issue your first short-lived user.

Quick start (API)

All responses use the standard { data: ..., meta: { request_id: "..." } } envelope. The examples below show the data fields.

Supported engines

See authentication modes for what each mode means and when to pick it.

Built-in role templates

Both templates create a user with the password KnoxCall generates and grant just enough permissions for the named scope. If neither fits, supply your own creation_sql + revocation_sql.

Next steps