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.
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 |
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 multiple tabs serving different purposes:
Your organization's LLM provider API keys (Anthropic, OpenAI, etc.) for independent billing. Supports multiple keys per provider with automatic LRU rotation. 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 and automatic disable on permanent failures.
Keys for accessing 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.