Transparency
How NameSniper Checks & Monitors
A plain-language account of the methods behind every availability result and alert - what we check, how we score confidence, and where the limits are.
Who's Behind This
NameSniper is an independent tool built for founders, creators, and developers who need to know, quickly and reliably, whether a name is available before they commit to it. Our focus is narrow and deliberate: domain availability across 20+ TLDs, handle availability across every major social and developer platform, and ongoing monitoring of handles you want to claim the moment they free up.
We don't scrape data to sell it, aggregate personal profiles, or build a database of who searched what. A search is a point-in-time availability check - nothing more. We persist only what the product needs: whether a handle was available or taken, and when we last checked.
This page exists because availability checking is not a solved problem. Social platforms change their APIs, add login walls, and deploy bot detection. DNS is fast but doesn't prove a domain is unregistered. We think you deserve to understand what confidence means when we say “likely available,” and what the honest edge cases are.
How We Check Availability
Domains and social handles use different mechanisms - both run on our edge network with no browser automation.
Domain Availability
A domain verdict rests on one rule: we never call a domain available on a weak signal. Fast checks can prove a domain is taken, but only the registries themselves can prove one is free - so an “available” verdict always traces back to authoritative registration data, with a commercial fallback for the few extensions that do not publish it.
That is why a taken verdict is definitive, and an available verdict comes from the source of record - not from the absence of a website.
Social & Developer Platform Handles
Social checking uses pure HTTP and official APIs - no browser automation, no Puppeteer, no headless Chrome. Every checker runs on our edge network with explicit per-platform timeouts, and all platforms are checked concurrently so results arrive in parallel, not one after another.
The strongest available signal, per platform
Every platform is checked through the most reliable route it offers - official interfaces where they exist, direct signals where they do not. Each verdict carries a confidence ceiling that reflects how trustworthy that route really is, and when a platform walls off access or serves bot-detection responses, the result is reported as unverified - never guessed into a false “available.”
Verified data for the hardest platforms
Instagram, TikTok, and Twitter/X actively hide account existence from automated checking. On paid plans, ambiguous results there are confirmed through verified data before we call them definitive. We pass only the handle string, and we receive and persist only the availability verdict and timestamp - never scraped profile data such as bio, follower count, or posts.
Confidence Scoring
Every result carries a confidence score. Here is what it means and why it can be less than 100%.
An official API returned a definitive result, or a registry-level RDAP response confirmed availability. For domains, that means an authoritative registry “not found.” For social, it means the platform's own official API reporting that no such account exists. Results at this level are what we use as the baseline for monitoring alerts.
Multiple signals point the same direction but no single authoritative source confirmed it. For example: an HTTP 200 on a profile page with matching og:title content, or a clean redirect to a search results page. Reliable for most use cases, but worth a manual spot check before buying a domain or committing to a brand.
The checker encountered bot detection, a login-wall redirect, a rate limit, or ambiguous signals. We never flip a low-confidence result into a monitoring alert. For interactive checks, we surface the result but label it uncertain so you know to verify manually before acting.
Why checks can be ambiguous
Social platforms serve different responses from datacenter IPs than from residential ones. Instagram and TikTok may redirect to a login page for both existing and non-existing profiles. Twitter/X may return a 200 with login-wall content regardless of whether the handle exists. In all of these cases, an ambiguous response is not the same as availability - we record it as uncertain and will not alert you about a handle we aren't confident about.
How Monitoring Works
NameSniper watches handles on a scheduled poll and alerts you only when it's genuinely confident a change happened. This system is newly deployed and under active validation as we open access - the design below reflects how it works today.
Scheduled polling
A scheduler runs on a fixed interval and re-checks your watches at the frequency your plan allows (Free: every 12 hours; Pro: hourly; Business: every 15 minutes). Watches are processed concurrently rather than one at a time, and the system is designed so that two overlapping runs can never double-check or double-alert the same watch.
Confirmed before you're alerted
A single poll showing a handle as “available” is never enough to send an alert. Platforms routinely return not-found responses for handles that are reserved, suspended, in a post-deletion hold, or behind bot detection - so every drop alert is re-verified before it reaches you, and ambiguous polls never change a watch's status. You get at most one external alert per watch per day, and when we say a name dropped, we mean it.
Our Data Sources
Where each type of information comes from, and how third-party services are disclosed.
Domain availability
- Public DNS resolvers - queried directly for delegation records (the fast first signal).
- Registry registration data - Authoritative records served by the domain registries themselves. No third-party markup.
- Commercial registration-data provider - Paid fallback, only for the few extensions without public registry data.
Social handle availability
- Official platform APIs - the official interfaces several major platforms provide. No third-party intermediary, application credentials only.
- Direct HTTP / platform endpoints - public-facing endpoints queried directly from our infrastructure for all other platforms.
- Paid verification provider - used only as a paid-user confirmation fallback for Instagram, TikTok, and Twitter/X. We pass the handle string; we receive and store only the availability verdict, never scraped profile data.
Trademark screening
USPTO trademark data via a commercial data service (9M+ live trademark records). When live data is unavailable, we fall back to heuristic similarity analysis. Trademark screening is advisory - always consult a qualified attorney before registering or using a brand name commercially.
What we persist
For monitoring, we store: the platform, the handle string, the last availability verdict (boolean), and the timestamp. We do not store scraped profile data - no display names, bios, follower counts, or any content from platform responses. Collecting or redistributing that data would violate most platform terms of service, and it is not needed for the availability signal.
How Often We Update
Platform response structures change. Login walls appear, get moved, or disappear. APIs introduce new response shapes. We review our checkers against live platform behavior whenever:
- A platform announces an API change or deprecation.
- Our monitoring detects a sustained drop in confidence scores for a platform (a signal that the response structure has changed).
- A user reports a result that appears incorrect.
- As part of general maintenance, at least quarterly.
Registry data mappings refresh automatically, so registry-level changes are tracked without manual work. Official API checkers are updated when platforms version or change their response schemas.
Honest Limitations
Availability checking has hard limits. Here are the ones that matter.
Datacenter IP ambiguity
Our checkers run from datacenter IP ranges. Instagram, TikTok, and Twitter/X all serve different responses to datacenter IPs than to residential ones - including presenting login walls for handles that do and don't exist alike. Our paid verification fallback mitigates this for paid users, but even that is not a guaranteed substitute for a logged-in session on the platform itself.
Reserved and non-claimable handles
A handle that reads as "available" on a platform profile check may still be non-claimable. Platforms reserve handles for trademarks, internal use, brand protection, and past policy violations. Short handles on Twitter/X (under 4 characters) are structurally not available to new registrations. A 404 from the platform is not a guarantee that you can register the handle - only an attempt to register it confirms that.
Handle-drop timing
We cannot predict or guarantee when a taken handle will free up. Platforms have their own internal hold periods after account deletion or deactivation (often 30-90 days before the handle returns to the pool, sometimes never). Monitoring tells you when the handle reads as available from our vantage point; it does not guarantee it will still be available by the time you try to claim it, or that the registration will succeed.
Platform rate limits
Platform APIs and endpoints impose their own rate limits. When a platform is actively rate-limiting our requests, a check can come back uncertain rather than definitive. We tune request rates per platform to stay within those limits and surface a low-confidence result rather than guessing when we are throttled.
Trademark results are not legal advice
Trademark screening against the USPTO database surfaces conflicts you should investigate further. It is a first-pass filter, not a comprehensive clearance search. It does not cover state-level marks, common-law rights, or international registrations. Always consult a qualified trademark attorney before relying on any automated trademark result.
Questions about our methods?
If you see a result that looks wrong or want to understand a specific platform's confidence score, reach out.