Request a takedown

In Doppel Vision, clicking Request Takedown on an alert sets its queue_state to actioned. The API equivalent is PUT /v2/alert with queue_state: "actioned".

This guide shows that mapping end to end, plus a few common variations: leaving a comment, attaching evidence, and tagging.

What you'll do

1. Get an OAuth access token (see Authentication).
2. Identify the alert by id (preferred) or entity.
3. PUT /v2/alert with queue_state: "actioned".

Request a takedown

cURL

curl --request PUT \
  --url "https://api.doppel.com/v2/alert?id=ACM-1234" \
  --header "Authorization: Bearer <YOUR_ACCESS_TOKEN>" \
  --header "Content-Type: application/json" \
  --data '{
    "queue_state": "actioned",
    "comment": "Confirmed phishing — proceeding with takedown."
  }'

Python

import requests

response = requests.put(
    "https://api.doppel.com/v2/alert",
    headers={"Authorization": f"Bearer {access_token}"},
    params={"id": "ACM-1234"},
    json={
        "queue_state": "actioned",
        "comment": "Confirmed phishing — proceeding with takedown.",
    },
)
response.raise_for_status()

Node.js

const url = new URL("https://api.doppel.com/v2/alert");
url.searchParams.set("id", "ACM-1234");

const response = await fetch(url, {
  method: "PUT",
  headers: {
    Authorization: `Bearer ${access_token}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    queue_state: "actioned",
    comment: "Confirmed phishing — proceeding with takedown.",
  }),
});

if (!response.ok) {
  throw new Error(`Takedown request failed: ${response.status}`);
}

The response is the full updated alert object, with queue_state: "actioned".

Recover from an unknown result

A timeout or a connection error can occur after the API accepts the update.
After this error, use GET /v2/alert with the same alert ID.

If queue_state is actioned, treat the update as successful. If the state did
not change, repeat the same PUT /v2/alert request one time. If the result is
still unknown, stop the workflow and report the error. Do not start a dependent
operation until you confirm the state.

Identifying the alert

PUT /v2/alert requires exactly one of id or entity as a query parameter:

• id=ACM-1234 — the id returned from POST /v2/alert.
• entity=https%3A%2F%2Fsuspicious-site.example.com — useful when you only have the URL or phone number. URL-encode the value.

Passing both, or neither, returns 400 Bad Request.

Optional: add a comment, evidence, or a tag in the same request

You can bundle additional changes with the queue-state update — they're applied atomically.

Add a comment

{
  "queue_state": "actioned",
  "comment": "Confirmed phishing — proceeding with takedown."
}

The comment is recorded on the alert.

Attach evidence

file_action and files must be sent together. Files are base64-encoded; up to 10 per request, 50MB each.

import base64

with open("evidence.png", "rb") as f:
    encoded = base64.b64encode(f.read()).decode()

requests.put(
    "https://api.doppel.com/v2/alert",
    headers={"Authorization": f"Bearer {access_token}"},
    params={"id": "ACM-1234"},
    json={
        "queue_state": "actioned",
        "file_action": "upload",
        "files": [{"file_name": "evidence.png", "file_to_upload": encoded}],
    },
)

Add or remove a tag

tag_action and tag_name must be sent together. Tags must already exist for your organization (or be global tags).

{
  "queue_state": "actioned",
  "tag_action": "add",
  "tag_name": "Credential Theft"
}

Other queue transitions

PUT /v2/alert applies the same queue policy as the Doppel Vision app. Two values are explicitly anchored to Doppel Vision behavior:

• actioned — the value to send for "Request Takedown" (this guide).
• taken_down — equivalent to Resolved in the Doppel Vision app. It is read-only: Doppel sets it when removal is confirmed, and a request that sends it is rejected with 400 Bad Request.

The remaining values (doppel_review, needs_confirmation, monitoring, archived) are accepted as targets. A request that names the alert's current queue is rejected. For actioned, the following also apply:

• Dark-web alerts cannot be moved to actioned; dark-web content cannot be taken down.
• When your organization requires customer confirmation for the alert's module, actioned is accepted only from doppel_review or needs_confirmation; from monitoring, taken_down, or archived the request is rejected until the alert is back in one of those review queues.
• When the alert carries the potential-false-positive tag, the request must include a comment of at least 15 non-whitespace characters.
• A trial organization that has used its takedown allowance receives 429 Too Many Requests.

Each policy rejection returns a message explaining the reason and a stable code. See Check the status of an alert for what each state means in the workflow, and the Update Alert API reference for the full request schema.

Status codes

Next steps

• Check the status of an alert — confirm the alert's queue_state is now actioned, and watch for further state changes.
• Submit a new alert — start tracking another entity.