Home/Offers/Cybersecurity, Identity & Fraud/Phishing URL Detection API

Cybersecurity, Identity & Fraud

Phishing URL Detection API

By the time a phishing domain appears on a public blocklist, the campaign using it has usually finished. The useful window is the first few hours, when nothing has reported it yet.

Email security vendors
Messaging platforms
Browser and extension developers
Banks
Managed security providers

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Phishing infrastructure is disposable. A domain is registered, given a certificate, used for six to forty-eight hours against a specific target, and abandoned. Blocklists built on user reports and abuse complaints are structurally behind that cycle — they describe what already happened. Any product that depends solely on list membership is protecting its users against last week.

The alternative is to score a URL on its own observable properties: registration age, certificate issuance pattern, the shape of the hostname relative to brands it resembles, redirect chains, hosting characteristics, and what the page itself contains if fetching it is permitted. None of those is conclusive. Together, on a domain registered ninety minutes ago that renders a login form branded for a large bank, they are fairly persuasive.

The honest difficulty is the other side of that trade. Every signal that catches a day-old phishing site also fires on a day-old legitimate site. Small businesses launch, campaigns get their own short-lived domains, and a newly registered host with a fresh certificate and a login form is sometimes exactly what it appears to be. A detector tuned hard enough to catch early campaigns will block real companies on their launch day, and the design has to confront that rather than bury it in a threshold.

Who buys this

Email security vendors, Messaging platforms, Browser and extension developers, Banks, Managed security providers

Category: Cybersecurity, Identity & Fraud

What the API returns

What comes back

Risk score per URL with the signals that produced it, each separately reported
Threat classification: credential phishing, payment fraud, malware delivery, scam, or unclassified
Brand-impersonation assessment where the host or page resembles a known brand
Domain and certificate age, registrar, and issuance pattern
Full redirect chain resolution with the final landing host
Hosting and network context including shared-infrastructure indicators
Page-content signals — forms, branding assets, obfuscated script — where fetching is permitted
A verdict band with an explicit uncertain category rather than forcing every URL into safe or malicious

Endpoints

Method	Path	Returns
POST	/v1/url/scan	Score a single URL, optionally fetching the page
POST	/v1/url/batch	Score a batch of URLs extracted from a message or document
GET	/v1/domain/{domain}	Domain-level profile: registration, certificates, history
POST	/v1/url/{id}/feedback	Report a false positive or a confirmed phishing outcome
GET	/v1/campaigns	Clusters of URLs sharing infrastructure or template
WS	/v1/stream	Push newly-scored high-risk hosts matching your brand watchlist

Request and response

illustrative

Request

{
  "url": "https://secure-login.examplebank-verify.com/auth",
  "fetch_page": true,
  "brand_watchlist": ["Example Bank"],
  "context": { "channel": "email", "recipient_domain": "clientco.com" }
}

Response

{
  "url": "https://secure-login.examplebank-verify.com/auth",
  "scanned_at": "2026-10-21T15:19:33Z",
  "verdict": { "band": "likely_malicious", "score": 88, "confidence": 0.79 },
  "classification": { "primary": "credential_phishing", "secondary": null },
  "signals": [
    { "signal": "domain_age_hours", "value": 31, "weight": 0.27 },
    { "signal": "brand_token_in_hostname", "value": "examplebank", "weight": 0.24 },
    { "signal": "login_form_with_foreign_post_target", "value": true, "weight": 0.21 },
    { "signal": "free_certificate_issued_with_domain", "value": true, "weight": 0.11 },
    { "signal": "hosting_shared_with_prior_phishing", "value": 4, "weight": 0.09 }
  ],
  "redirect_chain": [
    "https://t.example-tracker.net/c/9f21",
    "https://secure-login.examplebank-verify.com/auth"
  ],
  "brand_impersonation": {
    "brand": "Example Bank",
    "method": "hostname_token_plus_logo_match",
    "similarity": 0.91
  },
  "domain": { "registered": "2026-10-20T08:02:00Z", "registrar": "Example Registrar",
              "ns_changed_since_registration": false },
  "notes": ["Page fetched from a sandboxed egress; no credentials submitted"]
}

Where the data comes from

Certificate transparency logs	Public append-only logs of issued certificates — the fastest public notice that a hostname now exists
Passive DNS and zone data	New-domain feeds and resolution history, licensed where the provider requires it
Registration records	Registrar, creation date and nameserver changes, within what registry policy and privacy rules allow to be published
Your own message or traffic telemetry	URLs your gateway already sees, with your agreement — the highest-value training data because it matches your threat profile
Public abuse and blocklist feeds	Useful as confirmation and as training labels, not as the primary detection path, since they lag the campaign
Brand reference assets	Logos, domains and page templates for the brands you are protecting, supplied by you or the brand owner

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Separate feature families — lexical, registration, certificate, network, content — so a verdict can be produced from whichever are available for a given URL
Gradient-boosted scoring on tabular signals, with the content model kept separate so URLs that cannot be fetched still get a usable score
Brand-similarity matching combining hostname edit distance, homoglyph normalisation, and perceptual hashing of rendered page assets
Page fetching from a sandboxed, isolated egress that never submits input, never executes downloads, and identifies itself honestly in its user agent
Infrastructure clustering to group URLs into campaigns, which is what turns one detection into coverage of the whole batch
A deliberately wide uncertain band, because forcing a verdict on genuinely ambiguous new domains is where the damaging false positives come from
Adversarial review: we periodically test whether published detection logic could be used to tune evasion, and keep the sensitive weights out of customer-facing explanations
Drift monitoring against labelled feedback, with retraining cadence agreed up front since campaign technique changes within weeks

What it changes for the business

Earlier interception

Scoring on observable properties catches campaigns during the hours before any blocklist has heard of them.

Fewer blanket blocks

An explicit uncertain band lets you warn rather than block when the evidence is genuinely thin.

Campaign-level coverage

Infrastructure clustering extends one confirmed detection across the rest of the attacker's prepared domains.

Brand protection input

Hostname and asset matching feeds directly into whatever takedown process the brand owner runs.

How it fits into your product

How it embeds

Synchronous scoring for inline use in a gateway or browser extension, with a documented latency budget
Asynchronous deep scan with page fetch for cases where a few seconds is acceptable
Batch endpoint for all URLs in one message, returning the worst verdict plus the per-URL detail
Feedback endpoint wired to your own false-positive reports, which is the main lever on precision over time
Deployment inside your infrastructure where message content cannot leave your environment
Brand watchlists per tenant, so a managed provider can run one deployment across many customers

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

What is your false positive rate on new legitimate domains?

Non-trivial, and we would not pretend otherwise. A business that registered its domain yesterday, got a free certificate with it, and put a login form on it is indistinguishable on registration signals from a phishing site. Content and brand signals help; they do not resolve it. That is why there is an uncertain band, why we recommend warn-not-block on it, and why the feedback loop matters more here than almost anywhere else.

Does this keep working as attackers adapt?

Partially, and it needs maintenance. This is an adversarial problem: publish a detector and someone tunes around it. Registration-age signals stay useful because the economics of disposable infrastructure do not change easily. Specific content heuristics decay within months. Any proposal that implies a one-time build and no retraining budget is misleading, so we scope a retraining cadence into the engagement.

Do you fetch the page? Is that safe?

Only when you ask for it, and from an isolated sandbox with its own egress, no credential submission, no download execution and an honest user agent. Some sites cloak against known scanners, so a fetched verdict can differ from what a victim sees. The response says whether the fetch succeeded and whether cloaking was suspected.

Can you guarantee a URL is safe?

No. A low score means no evidence of malice was found in the signals available, which is not the same as safety. A compromised legitimate site with a long history and a valid certificate will score low until the compromise is observable. We would resist any UI wording that turns a low score into a safety guarantee.

Can we rely on this instead of a commercial threat feed?

That is a question for your security team and your coverage obligations. In practice this works best alongside list-based sources rather than instead of them: lists are strong on known-bad and weak on new, this is the reverse. If your compliance posture names a specific commercial provider, keep it and use this to close the early-hours gap.

All Cybersecurity, Identity & Fraud offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers