A support queue is the one inbox in your company that is professionally obliged to open attachments from strangers and click the links they send. It is also the brand most convincingly faked by the people attacking your customers. Screen every domain that enters or leaves the queue against a database of DNS-verified, currently live phishing hosts.
Everything that follows on this page hangs off one distinction. Threats arrive into the queue aimed at your agents, and threats go out wearing your support brand, aimed at your customers. Different controls, different owners, one domain database.
Anyone on the internet can open a ticket. That is the entire point of a support desk, and it is also the reason a support desk is the softest human target in most companies. Your agents are measured on first-response time and resolution rate. They are trained, culturally and by their own metrics, to open the thing the customer sent and figure out what is wrong with it. An attacker does not need to defeat a spam filter to reach them; they need to fill in a web form.
The other half of the problem never touches your infrastructure at all. Somebody registers a domain that looks like your support subdomain, stands up a copy of your help centre, buys a search ad against your own product name, and waits for a frustrated customer to type "how do I contact support" into a search box. The customer arrives, types their password into a fake chat widget, and every part of the incident happens outside your logs.
These two directions share almost nothing operationally. Inbound belongs to whoever owns the ticketing platform — usually a support-operations engineer with admin rights to the helpdesk and a rule engine to work with. Outbound belongs to brand protection, marketing, or a security analyst who spends their week filing takedown requests. In most companies the two never talk, which is how you end up with an organisation that screens outbound marketing email rigorously and lets an unauthenticated stranger paste a link straight onto an agent's screen.
What they do share is the question they need answered, and it is a small, cheap, mechanical question: is this hostname a known, currently live phishing domain? That is exactly what the Phishing Detection API answers. It is a known-bad lookup over a continuously maintained database of DNS-verified phishing hosts — not a heuristic page classifier, not a sandbox, not a scoring model for a domain nobody has ever seen before. Understanding that boundary is what makes the integration advice on the rest of this page useful rather than aspirational.
The honest architecture, then, is layered. The API gives you a fast, unambiguous verdict on the fraction of links that are already confirmed bad, and that fraction is not small — support queues attract high-volume commodity campaigns, which is precisely the kind of infrastructure that ends up in a phishing feed within hours. For everything else you keep your own signals: domain age, whether the link points at a host your customers have ever legitimately used, whether the ticket came from an address that has ever transacted with you, and whether a brand-new requester is asking an agent to do something irreversible. The API removes the easy cases so your judgement can be spent on the hard ones.
Four ticket shapes account for almost all of it, and they escalate in cost as you go down the list. None of them require the attacker to defeat a control — they require an agent to do their job quickly.
Start with the ticket that has no question in it. The subject line is something like "issue with my last order" and the body is two sentences plus a link to a document. There is no order, there is no account, and the requester email was registered forty minutes ago. This is not a clever attack. It works because an agent under queue pressure opens the link before reading closely, and because the link is the only actionable thing in the ticket.
Reply-chain hijacking is the more expensive version. An attacker who has compromised a genuine customer's mailbox replies to a real, months-old thread with your desk. Everything about the message is legitimate: the address, the signature, the history, the ticket ID in the subject line. Your ticketing system happily appends it to the existing conversation, where it inherits all the trust the earlier exchange earned. The only new element is the domain in the link, which is why a per-message, per-domain check is worth so much more than a per-sender reputation score here.
Then there are the queues that exist to handle money. A billing or accounts-receivable queue is a phishing target with a routing rule attached. "Please find the revised invoice at the portal below" lands in front of a person whose whole job is to look at invoices, and whose credentials often reach a payments console. The same logic applies to an internal IT service desk: password-reset requests, MFA re-enrolments and software-install tickets all route to somebody who can change the state of an identity, which makes them worth targeting directly.
Finally, the awkward cases. Screenshots attached with filenames that contain a URL. Pasted browser console logs and stack traces with a callback host buried three lines down. Signature blocks. Auto-generated diagnostic bundles. These are not links your ticketing system renders as anchors, so no amount of "hover before you click" training touches them — but they are the ones an agent copies into a browser deliberately, because they are trying to reproduce a bug.
Extract hostnames from all four sources with the same regex pass, deduplicate to unique hosts, and send them together. A thread with thirty links usually contains six distinct domains.
Support is the part of a company customers go looking for when something has already gone wrong. They are anxious, they are in a hurry, and they will accept the first plausible-looking route to a human being. That combination is why fake support portals convert so well, and why the impersonation problem belongs on the same page as the ticket-screening problem even though the mechanics are unrelated.
Why impersonation is a support problemThe pattern repeats with small variations. A domain is registered that pairs your product name with a service word — help, care, support, billing, refund, verify — and a static copy of your help centre is dropped on it, often scraped directly from your real site so the styling is perfect. A chat widget on the page collects an email address and a password "to verify your account before connecting you to an agent." During a genuine outage, the same operators stand up a fake status page, because customers searching for outage news are pre-selected for urgency and low scepticism.
Search advertising makes this worse in a way most support teams underestimate. A customer who searches for your support line may see a paid result above your own organic listing, and paid results are trivially cheap to buy against a competitor's or a victim's brand name. Community forums attached to your product create a third surface: an answer that solves a real problem and includes a "patched driver" or "official installer" link gets upvoted by grateful users, and it stays in your search results for years.
None of this is visible from inside your ticketing system, which is the core operational problem. You find out because a customer tells an agent they already reset their password on a page you do not run. The practical response is to make discovery systematic rather than anecdotal: build a candidate list of lookalike hostnames from certificate transparency logs, registrar zone files, your own referrer data and search-ad monitoring, then run that list against the API on a schedule. Anything already confirmed in the database is a takedown you can file today with evidence attached. Our brand protection use case covers the monitoring side of that workflow in more depth.
Feed candidates in through POST /api/v1/batch in blocks of 100. A confirmed match returns category: "phishing/malware" and dns_status: "resolves", which is the DNS evidence a registrar abuse desk asks for.
A domain check is only useful at the moment somebody is about to act on the link. Here is the sequence we would build, from the ingest pipeline through to the retrospective sweep that runs long after the ticket is closed.
Whatever creates tickets — an email connector, a web form, a chat transcript writer, an API integration — passes through one middleware. It walks the message body, the subject, the attachment filename list and any code blocks, pulls out every hostname it can find, lowercases them, strips the scheme and path, and reduces the result to a unique set. A long support thread routinely produces thirty raw URLs and six distinct hosts, and you only ever pay for the six.
Send the unique hosts to POST /api/v1/batch with your key in the JSON body. The endpoint accepts up to 100 domains per request and charges one credit per domain, returning results[] alongside checked, phishing_found and credits_used. Cache the verdict for the ticket's lifetime and key the cache on the hostname, not the full URL — a campaign that generates a unique path per victim still resolves to the same handful of hosts.
This is the highest-value part of the whole integration and the cheapest to build. Every link in the agent console gets a small badge rendered beside it before the agent has hovered anything: a green tick for checked-and-clean, a red block for a confirmed match, a grey dash for unknown. The grey state matters as much as the red one, because it tells the agent honestly that the system has no opinion rather than implying safety by silence.
When is_phishing comes back true, do not merely decorate the link. Move the ticket into a quarantine view, suppress the auto-reply that would otherwise acknowledge the sender, strip or defang the anchor so a click cannot happen accidentally, and post an internal note with the matched domain and its last_checked date. Quarantine should be a queue a senior agent reviews, not a black hole, because a legitimate customer occasionally pastes a link they were themselves phished with.
Macros, canned replies, signature templates and knowledge-base articles are all authored content that reaches thousands of customers with your name on it. Run the same check at save time in the authoring UI and block publication on a confirmed match. The threat model here is not a careless writer; it is a compromised author account, or a well-meaning agent pasting a "documentation" link a customer gave them. The same gate belongs on community forum posts at submit time.
The database rebuilds every 24 hours and the daily build lands at 04:30 UTC, which means a domain that was unknown on Tuesday can be confirmed on Wednesday. A scheduled job that walks the distinct hosts seen in the last 30 days of tickets and re-checks them turns yesterday's silence into today's incident ticket. This is the single feature incident responders ask for by name, because it answers "who did we expose, and when" without a manual log trawl.
When a retro sweep flags a domain, you already know which tickets carried it, which agents opened those tickets, and what times they were viewed. Hand that to whoever runs your response process — see incident response for the wider workflow — along with the domain, its category and DNS status. The value of the sweep is that it converts a vague "we might have been targeted" into a bounded list of accounts to reset.
Every design decision above follows from four properties of the data: how large it is, how often it changes, how much of it you can ask about at once, and how confident a match is.
Only domains with an active A record are included, so parked and abandoned infrastructure drops out of the set rather than accumulating in it. That matters for a support desk more than for most integrations: a stale blocklist that quarantines tickets containing long-dead domains trains agents to ignore the badge, and a badge agents ignore is worse than no badge at all. The open /api/v1/stats endpoint reports the current database size and last update without consuming credits or requiring a key, which makes it a convenient health check for a monitoring dashboard.
Support stacks differ enormously in how much of the platform you actually control. Pick the shape that matches your access, and expect to run two of them together rather than one perfectly.
The strongest option, and the only one that can stop a ticket before an agent sees it. If tickets reach you through a mail connector or a webhook you own, put the extraction and the batch call in that path and write the verdict onto the ticket as a custom field. Everything downstream — views, routing rules, SLA timers, reporting — can then reason about the field without knowing anything about the API. Budget for a short timeout and a fail-open default, because a support desk that stops accepting tickets is a worse outcome than a support desk that occasionally renders an unchecked link.
Server side · full controlWhen the ticketing platform is a hosted product you cannot extend server-side, an extension that annotates links in the agent console is the pragmatic answer. It scans the rendered DOM, collects hostnames, and asks your backend for verdicts. The extension must never hold the API key — the key is your username from registration and it belongs on a server you run, behind a thin proxy endpoint that authenticates the agent's session and applies its own rate limit. An extension shipping a key to every agent's browser is a key you have published.
Client render · proxy requiredA cron task that reads the distinct hostnames observed in the last 30 days of tickets and re-checks them in batches of 100. Run it after 05:00 UTC so it always reads the day's fresh build. This shape needs no changes to your ticketing platform at all, which makes it the easiest thing to ship first and the best thing to demo to a security stakeholder: it produces a list of tickets and agents associated with domains that are confirmed bad today, regardless of what anybody believed at the time.
Batch · retrospectiveThe Daily Threat Feed ships the full database as CSV or JSON with columns domain,category,dns_status, plus a changelog of what was added and removed each day. Load it into the DNS resolver your support floor uses — Pi-hole, BIND RPZ, Unbound — and an agent who clicks anyway simply gets nowhere. This is the fail-closed layer underneath everything else, it costs nothing per click, and it protects the links your extraction logic missed.
In practice the combination we would recommend for a mid-sized desk is the scheduled job plus the resolver feed on day one, then the ingest middleware once you have evidence to justify the engineering time. The scheduled job costs almost nothing to build and immediately tells you how big your problem is; the resolver feed protects everyone on the floor without anybody changing how they work. Those two together give you the numbers you need to argue for the inline badge, which is the part that requires real product work.
If you already run a SIEM, send the verdicts there as events rather than leaving them in the ticketing platform. A record of "ticket 48213 contained a confirmed phishing domain, viewed by three agents" is far more useful sitting next to your authentication logs than buried in a helpdesk custom field, and it lets a detection engineer correlate a click with the session activity that followed it. Our SIEM integration page covers the ingestion patterns for Splunk and QRadar.
One deployment note that applies to all four shapes: the check endpoint strips http://, https:// and path segments for you, so you can pass a full URL to GET /api/v1/check without pre-parsing it. That is convenient for a quick prototype, but for anything running at volume you should still normalise and deduplicate to bare hostnames yourself, because that is the only way to know how many credits a given ticket will actually cost before you spend them.
A single ticket thread carries far more links than people expect. A bug report with a stack trace, three screenshots, a documentation reference and an eight-message history can easily contain forty URLs. Sent naively, that is forty credits for one ticket. Reduced to unique hostnames it is usually five to eight, because the same documentation host, the same image CDN and the same tracking domain repeat throughout the thread.
So the sequence is fixed: extract, normalise to lowercase bare hostnames, deduplicate within the ticket, subtract anything already in your local cache or your own allowlist of hosts you obviously trust, and only then batch what remains into groups of 100. The batch endpoint's response tells you exactly what you spent through credits_used, so you can log per-ticket cost from the first day and know whether your allowlist is earning its keep.
The arithmetic is easy to sanity-check against the published packages. Assume a desk handling 2,000 tickets a day and, after deduplication and caching, an average of three billable hostnames per ticket. That is roughly 6,000 credits a day, or about 180,000 a month. At the Professional package — Professional at $249/month for 100,000 lookups, $0.0025 per lookup — you are looking at something in the region of $450 a month; at Business, Business at $499/month for 250,000 lookups, one package covers the month with headroom. lookups reset monthly, so buying a larger package for the better unit rate does not strand budget in an expiring balance.
| Package | Price | Credits | Per lookup |
|---|---|---|---|
| Starter | $59 | 10,000 | $0.0040 |
| Professional | $249 | 100,000 | $0.0025 |
| Business | $499 | 250,000 | $0.0020 |
If your volume is high enough that per-lookup pricing starts to dominate, the calculus flips toward the feed. A feed subscription is a flat $499 a month and includes 100,000 API credits, which means very high-volume desks can serve the common path locally from a loaded copy of the database and keep the API for the cases where they want a fresh, authoritative answer. The pricing page lists every package from Starter at $59 through to Enterprise at $999/month for 750,000 lookups credits, and the crossover point is easy to compute once you have a week of real per-ticket numbers.
# unique hosts extracted from ticket 48213 curl -s -X POST \ https://phishingdetectionapi.com/api/v1/batch \ -H 'Content-Type: application/json' \ -d '{ "apikey": "YOUR_KEY", "domains": [ "docs.example.com", "cdn.example-images.net", "secure-billing-verify.example", "status.example.com" ] }' # response carries checked / phishing_found / credits_used # and a results[] entry per domain with is_phishing, # category, dns_status, last_checked and confidence
The most damaging support-desk incidents are rarely about a clicked link. They are about an agent being talked into an action: resetting a password, re-enrolling an authenticator on a new device, adding a forwarding rule, changing a payout account, or reading back the last four digits of something. The caller is calm, well briefed, apologetic about the inconvenience, and has clearly done their homework on your internal vocabulary.
A domain lookup does not solve social engineering, and it would be dishonest to claim otherwise. What it does is give the agent one more mechanical, non-judgemental check to lean on at the moment they feel pressure — and mechanical checks are what let a junior agent say no to a persuasive adult without having to be personally brave. If the requester is pointing at a page, a portal, a document or a "verification link", that hostname goes into the check before anything else happens.
What a lookup can and cannot doBuild it as a single field in the agent console: paste a domain, hit check, get an unambiguous answer with the category, the DNS status and the date it was last verified. Make the result auditable by writing it to the ticket automatically. The point is not that the check will catch every pretext — it will not — but that the workflow now contains a step where the agent pauses, and the pause is where a scripted caller's story starts to fall apart.
Pair that with policy that removes the judgement call entirely for the highest-risk actions. Credential resets and MFA re-enrolment should go through an out-of-band verification path that the agent cannot bypass under pressure, no matter how convincing the request. A confirmed phishing match on a domain the requester supplied should be an automatic escalation rather than a discretionary one. Teams running structured awareness programmes for their support floor will find the security awareness page a useful companion here.
GET /api/v1/check?domain=example-support.test&apikey=KEY { "domain": "example-support.test", "is_phishing": true, "category": "phishing/malware", "dns_status": "resolves", "last_checked": "2026-07-26", "confidence": 0.98, "database_size": 212370 }
The same endpoint accepts a full URL and strips the scheme and path itself, which makes it usable directly from an agent's paste without any front-end parsing.
Practical answers about scope, cost, false positives and what happens to the links the database has never seen.
It looks up a domain. The service answers one question — is this hostname a known, currently live phishing domain — against a continuously maintained database of DNS-verified entries. It does not render the page, take a screenshot, analyse the HTML, or score an unknown domain heuristically. That is a deliberate boundary and it is why the verdict is fast and unambiguous when it fires.
For a support queue this shape works well because commodity campaigns aimed at support inboxes reuse infrastructure heavily. But it means you must design the unknown case explicitly: a null result is "no match today", not "this is safe", and your agent-facing UI should say exactly that.
Design the quarantine as a queue with an owner and an SLA, not as a silent drop. When a ticket is held, a senior agent should see it in a dedicated view with the matched domain, its category and its last_checked date, and be able to release it in one click with a logged reason. Track release rate as an operational metric; if it climbs, something upstream in your extraction is wrong — usually a redirector or link-shortener host being treated as the destination.
Also keep an internal allowlist of hosts your business genuinely depends on and check it before you spend a credit. It reduces both cost and noise.
No. The API key is the username you chose at registration and it authorises spending against your credit balance, so it belongs on a server you control. An extension that embeds the key ships it to every agent workstation and, in practice, to anyone who unpacks the extension.
The correct shape is a thin proxy endpoint on your own infrastructure: the extension authenticates with the agent's existing session, your server holds the key, applies its own rate limit and cache, and calls the batch endpoint. That also gives you a single place to log what was checked, which you will want anyway.
The database is refreshed every 24 hours and the daily build lands at 04:30 UTC. Every entry is DNS-verified through rotating proxy infrastructure, and only domains with an active A record are kept, so entries that go dark drop out instead of lingering.
That cadence gives you a natural cache policy: cache a verdict for the working day, expire it after the next build, and re-check anything that is still operationally relevant. It is also the reason the nightly re-screen of the last 30 days is worth running — a domain unknown at ticket time can be confirmed the following morning.
Credits are monthly subscription and billed monthly. Packages run from Growth at $99/month for 25,000 lookups ($0.0040 per lookup) up to Enterprise at $999/month for 750,000 lookups (per lookup on the Enterprise plan), with Professional at $249/month for 100,000 lookupsand Business at $499/month for 250,000 lookupsin between.
The number that decides your package is billable hostnames per ticket after deduplication and caching, not raw links. Measure it for a week with a scheduled job before you commit, and remember that the batch endpoint reports credits_used on every response so the measurement is free to instrument. Full details are on the pricing page.
Both, for different jobs. The feed is a flat monthly subscription that gives you the entire database as CSV or JSON plus a daily changelog of additions and removals, and it is built for DNS sinkholes, firewall blocklists and SIEM ingestion. Loading it into the resolver your agents use makes every click fail closed at no marginal cost.
The API is what you use inline, where you want a per-domain answer at ticket ingest or in an agent console with the current database behind it. A large desk typically runs the feed at the network layer and the API in the ingest path. See the daily feed page for delivery options.
It confirms them, which is the part that unblocks action. You still need to generate the candidate list yourself — from certificate transparency, registrar data, referrer logs, search-ad monitoring, and reports from customers who tell an agent they used a page you do not run. Feed those candidates through the batch endpoint on a schedule.
A confirmed hit gives you the category and DNS status showing the host actively resolves, which is the evidence a registrar or hosting abuse desk expects. The service does not file takedowns for you; it tells you which of your suspicions are already confirmed so you can prioritise the ones that are live.
Pick a monthly plan, run a week of your own ticket data through the batch endpoint, and find out how many confirmed phishing domains have already reached your support queue. Credits are monthly subscription and billed monthly, and the stats endpoint needs no key or credits while you build.
