Skip to main content

API keys

API keys connect a sending system to a tenant and a source_id.

What this page is for​

Use this page when a system needs permission to send events into Esper.

Typical examples:

  • Your web application.
  • Your backend API.
  • A partner integration.
  • An internal service.

What an API key contains​

The current API key model includes:

  • api_key_id: The unique identifier for the API key record.
  • tenant_id: The tenant that owns the API key.
  • name: The human-readable label for the key.
  • source_id: The source identifier attached to traffic from this key.
  • trust_level: The trust classification Esper applies to this source.
  • created_at: When the API key was created.

When creating a key, the console collects:

  • name: The label operators see in the dashboard.
  • source_id: The source name or ID the sending system represents.
  • trust_level: The trust level for requests signed by this key.
  • secret: The shared secret used to authenticate requests.

Frontend API contract​

GET /tenants/{tenant_id}/api-keys
POST /tenants/{tenant_id}/api-keys
PATCH /tenants/{tenant_id}/api-keys/{api_key_id}
DELETE /tenants/{tenant_id}/api-keys/{api_key_id}

How this connects to the rest of the system​

  • Ingest sources authenticate with API keys.
  • Events retain source_id.
  • In brokered deployments, the control plane forwards ingest work to the ingestion broker before engine evaluation.

This means API keys remain the first operational link between tenant traffic and the policy builder.