Request a takedown
Request a takedown
In Doppel Vision, clicking Request Takedown on an alert sets its queue_state to actioned. The API equivalent is PUT /v1/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
- Authenticate (see Authentication).
- Identify the alert by
idorentity. PUT /v1/alertwithqueue_state: "actioned".
The examples below show the organization-wide auth mode (
x-api-keyonly). For the user-specific mode, also sendx-user-api-key(andx-organization-codeif your user belongs to multiple organizations) — see Authentication.
Request a takedown
cURL
curl --request PUT \
--url "https://api.doppel.com/v1/alert?id=ACM-1234" \
--header "x-api-key: <YOUR_ORG_API_KEY>" \
--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/v1/alert",
headers={"x-api-key": "<YOUR_ORG_API_KEY>"},
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/v1/alert");
url.searchParams.set("id", "ACM-1234");
const response = await fetch(url, {
method: "PUT",
headers: {
"x-api-key": "<YOUR_ORG_API_KEY>",
"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".
Identifying the alert
PUT /v1/alert requires exactly one of id or entity as a query parameter:
id=ACM-1234— theidreturned fromPOST /v1/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/v1/alert",
headers={"x-api-key": "<YOUR_ORG_API_KEY>"},
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 /v1/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 with400 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,
actionedis accepted only fromdoppel_revieworneeds_confirmation; frommonitoring,taken_down, orarchivedthe 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
commentof 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
| Status | Meaning |
|---|---|
200 OK | Alert was updated. The full updated alert is returned. |
400 Bad Request | Both or neither of id / entity was provided, the body had no fields to update, a paired field was missing (e.g. tag_action without tag_name), or the requested queue_state is not allowed by the queue policy above. |
401 Unauthorized | Missing or invalid auth headers. |
404 Not Found | No alert in your organization matches the supplied id or entity, or a referenced tag was not found. |
429 Too Many Requests | Rate limit exceeded, or the request moved an alert to actioned for a trial organization that has already used its takedown request allowance. The response body message says which (for the trial case, that the takedown allowance is exhausted); retrying the trial-limit case will not help. |
Next steps
- Check the status of an alert — confirm the alert's
queue_stateis nowactioned, and watch for further state changes. - Submit a new alert — start tracking another entity.
Updated 27 days ago
