Create API keys for programmatic access to Entity Enricher. Use organization access keys for service-to-service integration, CI/CD pipelines, and automated workflows.
Entity Enricher supports two types of API keys, each suited for different use cases:
Standalone keys with their own role, not tied to any user account. The best choice for service-to-service integration.
Keys tied to a specific user account. They inherit the creator's role and are affected by user account changes.
ent_a1b2c3d4e5f6g7h8Keys use the ent_ prefix followed by random bytes. The full key is shown only once at creation time — it cannot be retrieved later.
Access keys (for calling Entity Enricher's API) are stored as SHA256 hashes in the database, so even with database access, the original key cannot be recovered. Only the first 12 characters (the prefix) are stored in plain text for identification.
Provider keys (LLM API keys like Anthropic, OpenAI) are encrypted at rest using Fernet symmetric encryption (AES-128-CBC + HMAC). They must be decryptable at runtime to authenticate with LLM providers. Only the last 4 characters are stored in plain text.
ent_ prefix and a hash, so a key that was not copied here is replaced, never recovered.Create keys from the API Keys page in the application, or programmatically via the REST API:
| Field | Description |
|---|---|
| Name | A descriptive name for identification (e.g., "CI/CD Pipeline", "n8n Integration") |
| Role | The permission level: owner, editor, or operator. Determines what the key can access. |
| Scopes | read, write, or both. Controls whether the key can modify data or only read it. |
| Expiration | Optional expiration date. Keys without expiration last until revoked. |
Send your API key in the X-API-Key header with every request:
curl -H "X-API-Key: ent_your_key_here" \
https://your-instance.example.com/api/enrichment/options| Method | Header | Use Case |
|---|---|---|
| API Key | X-API-Key: ent_... | Service-to-service, CI/CD, automation |
| Bearer Token | Authorization: Bearer <jwt> | Web clients, interactive sessions |
| OAuth 2.1 | Authorization: Bearer <access_token> | Connectors and AI clients — a revocable grant per app, not a shared key |
The API key's role determines which endpoints it can access:
| Endpoint Category | Minimum Role |
|---|---|
| Enrichment (single, batch) | Operator |
| Records (list, detail, delete) | Operator |
| Schema (read) | Operator |
| Schema (create, edit, delete) | Editor |
| Fusion | Operator |
| Provider info | Operator |
| Cost analytics | Operator |
| API key management | Owner |
| User management | Owner |
The API Keys page provides a complete view of all organization keys with usage statistics:
The API Keys page has five tabs serving different purposes — four of them for everyone, plus Global Keys for system administrators:
Your organization's LLM provider API keys (Anthropic, OpenAI, etc.) for independent billing. Supports multiple keys per provider with automatic LRU rotation; a key whose test fails leaves the rotation until it is re-tested or replaced. See Models & Pricing for the BYOK system.
Provider keys are encrypted at rest using Fernet symmetric encryption (AES-128-CBC with HMAC authentication). They are decrypted only at runtime when making LLM API calls. Only the last 4 characters are stored in plain text for display purposes.
System-wide LLM provider keys managed by administrators. Used as fallback when no organization key is available. Supports multiple keys per provider with LRU rotation: the enabled key used longest ago goes next, and a key leaves the rotation when an administrator disables it or its test marks it invalid. With no usable key for a provider, a run is refused instead of started.
Organization access keys for Entity Enricher's own API. Used by external systems to call the enrichment, schema, records, and other endpoints programmatically. See the API Reference for endpoint documentation.
Applications you authorized over OAuth 2.1 — the claude.ai connector directory, Claude Desktop, Make and n8n connections. Each row is a revocable grant rather than a shared secret: revoking it here invalidates that app's tokens without touching your other integrations. Owners can also register an OAuth client for a self-hosted n8n instance.
Credentials for the self-service Ollama tunnel, which exposes a local Ollama to the platform without opening a port. See the Ollama Tunnel guide.