Screen a link for danger

This endpoint runs a fast structural screen of the URL itself and flags the red flags attackers lean on — link shorteners that hide the destination, an @ used to disguise the real host, a bare IP-address host, punycode lookalike domains — so you can hold, warn or take a closer look before a link reaches a user's screen. It reads the URL string; it does not follow redirects or look the domain up in a threat database.

Who ends up needing this

Teams that accept user-submitted links are the obvious case: chat apps, forum software, ticketing systems, comment sections, browser extensions. Less obvious but just as common are email platforms rewriting links at send time, ad networks vetting creative URLs, and internal tools that ingest URLs from spreadsheets or CRM exports nobody has looked at closely. Anywhere a URL crosses a trust boundary, a cheap structural screen has a job to do.

What actually happens to a URL

Submit a URL to POST /verify/url-safe and the task screens the string itself for the structural patterns attackers lean on: a known link shortener (bit.ly, tinyurl, goo.gl and the like) that hides where the link really goes, an @ in the URL used to make a hostile host look like a trusted one, a host that is a bare IP address instead of a domain, and punycode (xn--) sequences used to build lookalike domains. It returns a clear suspicious-or-not verdict with the flag that fired, not a bare score. It does not resolve the link, follow its redirects, or check it against a reputation feed — it is a structural screen, fast and cheap enough to run on every link.

A short history of a long problem

URL-based attacks have outlived nearly every other web threat category because the fix is structurally hard: a URL is just text until something resolves it, and by then the damage window has often opened. Shortened links made it worse by hiding destinations entirely, and lookalike domains built with punycode or a disguising @ now routinely slip past a hurried glance. Eyeballing a URL stopped being a reliable defense years ago, which is exactly why an automated first-pass screen for the obvious structural tricks is worth running on every link before anyone clicks.

Fitting it into a pipeline

Because the task is asynchronous, you fire the request at the moment a URL is submitted or ingested and move on; the verdict lands on your webhook, or you fetch it from a signed link valid for 24 hours if you prefer to poll. Failed checks are never billed, three retries happen automatically, and a request that still can't complete returns a clear error rather than a silent gap, which matters when the check is standing between a user and a click they cannot take back.

What it deliberately does not do

This endpoint screens the structure of the URL string; it does not follow redirects to a final destination, fetch the page, or look the domain up in a threat or reputation database. That means a malicious page on a clean-looking, un-shortened domain will pass this screen, and a shortened link is flagged for being shortened rather than resolved to what it hides. Pair it with verify.phishing when you need a content-level read on a landing page or an email; keeping the two separate is what keeps this check fast and cheap enough to run on every single link at submission time.