Authentication

The Doppel V1 API authenticates requests with static API keys passed as request headers. V1 supports two modes:

We strongly recommend user-specific authentication. Compared to organization-wide keys, user-specific keys are:

• Self-service — each user generates and manages their own key from Doppel Vision API settings, with no need to involve your Doppel representative.
• Self-rotatable — if a key is exposed, the owning user can revoke and reissue it immediately, again without Doppel involvement.
• Scoped by RBAC — requests run with the same role and permissions as the issuing user, so least-privilege access is enforced automatically.

Use organization-wide keys only when you need a shared service-account credential that isn't tied to a human user.

The two kinds of key are issued differently:

• User-specific API key (x-user-api-key) — self-service. Each user generates their own from Doppel Vision API settings.
• Organization-wide API key (x-api-key value used on its own in the org-wide mode) — contact your Doppel representative to get one. These are not self-service.

The x-api-key header is sent in both modes — the difference is whether x-user-api-key is also present.

User-specific (recommended)

Send both x-api-key and x-user-api-key. The request will act on behalf of the user identified by x-user-api-key, with that user's role and permissions.

cURL

curl --request GET \
  --url "https://api.doppel.com/v1/alerts" \
  --header "x-api-key: <YOUR_ORG_API_KEY>" \
  --header "x-user-api-key: <YOUR_USER_API_KEY>"

Python

import requests

response = requests.get(
    "https://api.doppel.com/v1/alerts",
    headers={
        "x-api-key": "<YOUR_ORG_API_KEY>",
        "x-user-api-key": "<YOUR_USER_API_KEY>",
    },
)

Node.js

const response = await fetch("https://api.doppel.com/v1/alerts", {
  headers: {
    "x-api-key": "<YOUR_ORG_API_KEY>",
    "x-user-api-key": "<YOUR_USER_API_KEY>",
  },
});

Organization-wide

Send a single header — your organization API key — in x-api-key. Use this mode only when you need a shared service-account credential not tied to a specific user; otherwise prefer user-specific authentication above.

cURL

curl --request GET \
  --url "https://api.doppel.com/v1/alerts" \
  --header "x-api-key: <YOUR_ORG_API_KEY>"

Python

import requests

response = requests.get(
    "https://api.doppel.com/v1/alerts",
    headers={"x-api-key": "<YOUR_ORG_API_KEY>"},
)

Node.js

const response = await fetch("https://api.doppel.com/v1/alerts", {
  headers: { "x-api-key": "<YOUR_ORG_API_KEY>" },
});

Selecting an organization (multi-organization users)

When the user identified by x-user-api-key belongs to multiple organizations, the request must say which one to act under by sending x-organization-code — your organization's three-letter code.

Per the V1 OpenAPI spec, x-organization-code is optional and is required only when the user belongs to multiple organizations.

cURL

curl --request GET \
  --url "https://api.doppel.com/v1/alerts" \
  --header "x-api-key: <YOUR_ORG_API_KEY>" \
  --header "x-user-api-key: <YOUR_USER_API_KEY>" \
  --header "x-organization-code: ACM"

Python

import requests

response = requests.get(
    "https://api.doppel.com/v1/alerts",
    headers={
        "x-api-key": "<YOUR_ORG_API_KEY>",
        "x-user-api-key": "<YOUR_USER_API_KEY>",
        "x-organization-code": "ACM",
    },
)

Node.js

const response = await fetch("https://api.doppel.com/v1/alerts", {
  headers: {
    "x-api-key": "<YOUR_ORG_API_KEY>",
    "x-user-api-key": "<YOUR_USER_API_KEY>",
    "x-organization-code": "ACM",
  },
});

Best practices

• Prefer user-specific keys — they're self-service, self-rotatable, and scoped to the issuing user's RBAC role.
• Store keys securely — never commit x-api-key or x-user-api-key values to version control.
• Use environment variables for both keys, not hard-coded literals.
• Rotate keys promptly if compromised — user-specific keys can be reissued by the owning user directly in Doppel Vision API settings; organization-wide keys require contacting your Doppel representative.

Next steps

• Submit an alert — report a URL or phone number for triage.
• Check the status of an alert — read an alert's queue_state and entity_state.
• Request a takedown — set an alert's queue_state to actioned.
• Migrating to V2 — V2 uses OAuth 2.0 client credentials with short-lived tokens.