API keys provide a simple, long-lived authentication method for scripts, automation, CI/CD pipelines, and third-party integrations that need to access SoCMate programmatically.

Creating an API Key

API key management requires the admin role. Only administrators can create, rotate, and disable API keys.

From the UI

Navigate to Admin > API Keys and click Create API Key. Provide a name, description, and select the scopes the key should have access to.

From the API

Response:
The full API key is only shown once in this response. Copy it immediately and store it securely (e.g., in a secrets manager). SoCMate stores only a salted hash of the key and cannot recover it.

Using an API Key

Pass the API key in the X-API-Key header with every request:

Synchronous investigation timeout

Omit background (or set it to false) to receive the investigation result in one response. The production ingress and frontend proxy allow up to 30 minutes of upstream inactivity. Configure your HTTP client to wait at least that long; for example, use curl --max-time 1860 to allow a small transport margin. These are proxy inactivity limits, not an investigation execution deadline. The frontend setting applies to its rewritten proxy requests, and the production ingress annotations apply to the routes on that ingress. Any additional proxy in a custom installation must also allow the required wait time.

Background investigations and polling

For long investigations, use background: true to avoid holding the request open through proxy timeouts. Set SOCMATE_API_KEY to a key with both investigations:write and investigations:read scopes:
The response contains session_id, run_id, and a browser session_url. Poll with the returned session ID using the same API key:
Check session.status every few seconds. Continue while it is initialized or active; stop when it becomes completed, failed, or canceled. The response also includes persisted messages, events, and tool_calls. A successful GET returns HTTP 200 even when the investigation status is failed. This reuses the session-history response: the POST options such as include_tool_calls and include_raw_results do not filter polling results. History may be partial while the investigation is running. Polling reads persisted state; it does not restart an investigation interrupted by a service restart. The public route requires investigations:read and ownership by the creating key ID. Rotating that key preserves ownership; creating a different key does not. Internal /api/v1/sessions/* routes continue to reject API keys. Missing or invalid authentication returns 401, insufficient scope or ownership returns 403, and an unknown session returns 404. For installations accessed through the frontend proxy, use https://<frontend-host>/proxy/agent/api/v1/public/... for both requests.

Scopes

Each API key is restricted to a set of scopes that control which endpoints it can access: A request to an endpoint outside the key’s scopes returns 403 Forbidden:

Key Rotation

Rotate an API key to generate a new secret without changing the key ID. This allows you to update integrations gradually with an optional grace period for the old key.
Response:
During the grace period, both the old and new API keys are accepted. This gives you time to update all integrations before the old key expires.

Listing API Keys

List all API keys with optional search:
Response:
The list never exposes the full API key value — only the key_prefix is shown.

Disabling an API Key

Disable a key to immediately revoke access:
Disabling a key also invalidates any grace-period previous key value. The key cannot be rotated after disabling.

Key Status

Best Practices

  • Use scoped keys — Only grant the minimum scopes needed for each integration
  • Set expiration dates — Do not create keys that never expire; use the expires_in_days parameter
  • Rotate regularly — Use the rotation endpoint with a grace period to update keys without downtime
  • Monitor usage — Check last_used_at in the admin panel to identify unused keys for cleanup
  • Use descriptive names — Name keys after the integration they serve (e.g., “SOAR Integration”, “CI Pipeline”)
  • Store securely — Use a secrets manager (Azure Key Vault, HashiCorp Vault) rather than embedding keys in code