Evidence your queue can act on.
A finding that cannot leave the tool it was found in is a finding nobody acts on. Everything here is queryable, exportable and addressable by API.
What a queue needs that a dashboard does not give it
Three things, and a dashboard reliably provides none of them.
It has to reach where the work happens
If a finding lives only behind a login, it competes with everything else for someone remembering to look.
The evidence has to travel with it
A domain name in a ticket is not actionable. The registration record, the DNS answers and the certificate entries are what make it triageable.
The threshold has to be defensible
Anyone can be asked why a finding was escalated. An undisclosed score cannot answer that; a published rule can.
What the platform gives a team
- Explore
Queries you can save
Filter findings by registration age, technique, ending, registrar, mail, status and more, then keep the query.
- Rules
Rules with a severity
A saved query becomes a rule that runs on every new report. A rule never changes a finding's published review priority.
- Every report
Exports that fit your tooling
JSON, JSONL and CSV, with formula characters escaped so a spreadsheet cannot execute a finding.
- Three endpoints
An API, not a scrape
Start a check with a bearer key and poll the job. Keys are scoped to check or read-only and stored only as hashes.
How it works
- 01
Check
Enter a domain. About 3,001 candidate names are generated across twenty pattern families, roughly 180 endings and forty hosting platforms, and every one is resolved over DNS.
- 02
Watch
Put the domain on a watchlist and it is re-checked daily, with certificate transparency logs searched every thirty minutes so a name being prepared reaches the report within the hour.
- 03
Review
Each finding carries the registration record, the DNS answers and the certificate entries it rests on, plus the published rule that ranked it. You mark it once and the decision sticks to the name.
- 04
Act
Export the evidence, raise an alert against a saved query, or take it to the registrar. Most findings stop at the first step, which is the point of ordering them.
The same finding, as your queue receives it
One finding from the API. Every field is either a value a public source returned or the rule that ranked it, so a ticket carries its own evidence.
GET /api/v1/jobs/7f3a2c
Authorization: Bearer $KEY
200 OK
{
"domain": "exmaple.com",
"technique": "transposition",
"editDistance": 1,
"registered": true,
"createdAt": "2026-09-06",
"registrar": "disclosed",
"registrant": null,
"addresses": ["192.0.2.24"],
"mail": true,
"certificates": 1,
"passiveObservations": null,
"priority": "elevated",
"rule": "active infrastructure on a registration under a year old",
"firstSeen": "2026-09-06",
"status": null
}Two fields are null on purpose. No passive observation exists because nobody has scanned the host, and the registrant is redacted by the registry, which is now the norm. Neither is reported as a negative, because an absent record and a record saying no are different facts and a triage decision should not confuse them. The same row exports as CSV with formula characters escaped.
What this does not do
Signed webhooks and Slack, Microsoft Teams and Discord delivery are part of Pro, alongside email, so an alert reaches a team where it already works. There is no SIEM connector. The API returns the same evidence and the same published priorities the panel shows, and nothing more.