API Access

DFIRe provides a full REST API for programmatic access. Use API keys to authenticate SIEM connectors, SOAR playbooks, custom scripts, and third-party integrations.

Overview

Every action available in the DFIRe web interface is also available through the REST API. API keys allow external systems to authenticate and perform operations with the same permission model as browser-based users.

Key concepts:

  • API Keys are per-user Bearer tokens that inherit the user's full RBAC permissions
  • Service Accounts are dedicated user accounts that authenticate exclusively via API key (no password or SSO login)
  • API Documentation is built into every DFIRe installation as an interactive reference at /api/docs/

API Keys

API keys provide programmatic access to DFIRe. Each key is tied to a specific user and inherits that user's group memberships, permissions, and case access. Any endpoint accessible via the browser is accessible via API key with the same authorization checks.

Creating an API Key

  1. Navigate to Settings > API Keys

    Any authenticated user can create API keys for their own account.

  2. Click "Create API Key"

    Provide a descriptive name (e.g., "Splunk SOAR connector") and set an expiration date. The expiration cannot exceed the tenant-configured maximum lifetime.

  3. Copy the raw key immediately

    The full key (starting with dfire_ak_) is displayed only once. Store it securely — DFIRe stores only a SHA-256 hash and cannot recover the original key.

Important: The raw API key is shown only at creation time and after regeneration. If you lose it, you must regenerate the key (which invalidates the old one).

Key Properties

Property Description
Name A descriptive label for identifying the key's purpose.
Description Optional notes about what system uses this key.
Expiration Mandatory. Keys automatically stop working after this date. Bounded by the tenant maximum lifetime setting.
Enabled Keys can be temporarily disabled without deletion. Disabled keys reject all requests.
Key Prefix The first 12 characters of the key (e.g., dfire_ak_a1b2), visible in audit logs for identification.

Managing API Keys

From the API Keys settings page you can:

  • Enable / Disable — temporarily suspend a key without deleting it
  • Regenerate — create a new key value (the old value stops working immediately)
  • Delete — permanently remove a key
  • View usage — see last used timestamp, IP address, and total request count

Tenant Policy

Administrators can configure API key policy in Settings > Global Settings:

Setting Default Description
Maximum keys per user 3 Limits the number of active (enabled and non-expired) keys a single user can have.
Maximum key lifetime 365 days The furthest expiration date allowed when creating or regenerating a key.

Admin Key Management

Users with the change_tenant permission (superusers and tenant administrators) can manage any user's API keys from the user detail view. This includes listing, disabling, and deleting keys belonging to other users.

Password change revocation: When an administrator changes another user's password, all of that user's enabled API keys are automatically disabled as a security measure. The user must re-enable or regenerate their keys. Changing your own password does not affect your keys.

Service Accounts

Service accounts are dedicated user accounts designed for automated systems. They authenticate exclusively via API key — password login and SSO are blocked.

Creating a Service Account

  1. Create a new user account

    Go to Settings > User Management and create a regular user account (e.g., svc-splunk).

  2. Enable the service account flag

    In the user's profile, check "Service Account". This blocks password and SSO login, and hides the account from non-admin user listings.

  3. Assign appropriate groups

    Add the service account to the groups that grant the permissions it needs. Follow the principle of least privilege.

  4. Create an API key

    As an administrator, create an API key for the service account from Settings > API Keys using the user selector.

Custom Permissions via Groups

API keys inherit all permissions from the user account they belong to, including group memberships. To grant a service account (or any API key holder) a custom set of permissions, create a dedicated user group and assign only the rights that integration needs. Group creation is available exclusively through the Django admin panel at /admin/auth/group/. Once a group exists, its permissions can be managed from either the Django admin or from DFIRe Settings > User Management by editing the group. Assign the service account to this group to activate the permissions. This approach lets you enforce least privilege — for example, a SIEM connector group might only have view permissions on cases and indicators, while a SOAR playbook group could additionally have add and change permissions on cases.

Audit trail: All actions performed via API key are logged with the key prefix (e.g., dfire_ak_a1b2...) in the audit log, making it easy to trace which integration performed each action.

Authentication

API requests are authenticated using the Authorization header with a Bearer token:

Authorization: Bearer dfire_ak_your_key_here

Example: List Cases

curl -H "Authorization: Bearer dfire_ak_abc123..." \
     https://your-dfire-instance.com/api/cases/

Example: Create a Case

curl -X POST \
     -H "Authorization: Bearer dfire_ak_abc123..." \
     -H "Content-Type: application/json" \
     -d '{"title": "Phishing incident", "case_mode": "incident", "severity": "high"}' \
     https://your-dfire-instance.com/api/cases/

Authentication Behavior

Scenario Result
Valid, enabled, non-expired key Request proceeds with the key owner's permissions
Expired key 401 Unauthorized
Disabled key 401 Unauthorized
Invalid key value 401 Unauthorized
Key owner's account is inactive 401 Unauthorized
Too many failed attempts from same IP 401 Unauthorized (rate limited)
No Authorization header Falls through to session auth (browser login)
Brute-force protection: After 10 failed authentication attempts from the same IP address within 5 minutes, further API key authentication is blocked for 10 minutes. Successful authentication resets the counter.

API Documentation

Every DFIRe installation includes built-in API reference documentation generated from the live application. The documentation is always up-to-date and reflects the exact endpoints, parameters, and response formats available in your version.

Accessing the API Reference

Resource URL Description
API Reference /api/docs/ Interactive ReDoc documentation with endpoint descriptions, request/response schemas, and authentication details.
OpenAPI Schema /api/docs/schema/ Raw OpenAPI 3.0 YAML schema. Import into Postman, Insomnia, or code generators.

Both endpoints require authentication (browser session or API key). Links are also available in Settings > Global Settings under the API Documentation section.

Key Endpoint Groups

The API is organized into the following groups:

Group Base Path Description
Cases /api/cases/ Case CRUD, timers, indicators, timeline, exports
Items /api/items/ Evidence item management
Attachments /api/attachments/ Encrypted file uploads and downloads
IOC /api/indicators/ Indicator registry, enrichment, bulk operations
API Keys /api/api-keys/ API key management
Users /api/users/ User management and profiles
Search /api/search/ Full-text search across all entities
Webhooks /api/webhooks/ Outgoing and incoming webhook configuration
Audit Log /api/audit-logs/ Immutable audit trail
System /api/system-settings/ Tenant configuration and admin operations

See the built-in API reference at /api/docs/ for complete endpoint details, request/response schemas, and parameter documentation.

Security Best Practices

  • Use service accounts for integrations — avoid using personal API keys for automated systems. Service accounts make it clear which permissions are granted to which integration.
  • Set short expiration dates — rotate keys regularly. Use the shortest lifetime that is practical for your integration.
  • Store keys in secrets managers — never hardcode API keys in scripts, configuration files, or version control. Use your platform's secrets management (AWS Secrets Manager, HashiCorp Vault, environment variables).
  • Apply least privilege — create dedicated groups with minimal permissions for each integration. A SIEM connector that only reads cases should not have write access.
  • Monitor usage — review API key usage statistics and audit logs regularly. Disable keys that show unexpected activity or are no longer in use.
  • Disable before deleting — if you suspect a key may be compromised, disable it first to immediately block access, then investigate before deciding whether to delete or regenerate.