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 20 social and developer platforms, 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 are edge-native, running on Cloudflare Workers with no browser automation.
Domain Availability
Domain checking uses a two-tier cascade designed around one insight: DNS can prove a domain is registered, but it cannot prove a domain is free. A registered domain can have no DNS records at all (parked, email-only, brand-reserved). So we never report “available” from DNS alone.
DNS-over-HTTPS fast-path (~300ms)
We query both Cloudflare and Google DoH resolvers for NS records. If either returns a delegation, the domain is definitively taken — NS records only exist for registered domains. This gives us a fast TAKEN verdict without a round-trip to the registry.
RDAP authoritative confirm (~600ms)
When DNS shows no delegation (potential NXDOMAIN), we confirm using RDAP — the Registration Data Access Protocol, the free IETF successor to WHOIS served directly by the domain registries. An RDAP 404 is the registry saying “this domain is not in our records,” which is an authoritative available verdict. A 200 means it is registered. We resolve the correct RDAP endpoint per TLD via the IANA bootstrap registry rather than hard-coding URLs. This covers all common gTLDs (.com, .net, .org, .app, .dev, .io) for free.
WhoAPI fallback (ccTLD gaps only)
A small number of country-code TLDs (.co, .me, and similar) lack public RDAP endpoints. For these, when a WhoAPI key is configured, we fall back to a paid registrar lookup. Most TLDs we offer are covered by RDAP at no cost; this tier only activates when RDAP has no endpoint for the requested extension.
Social & Developer Platform Handles
Social checking uses pure HTTP and official APIs — no browser automation, no Puppeteer, no headless Chrome. Every checker runs on Cloudflare Workers using fetch() with User-Agent headers, explicit timeouts (5–8s per platform), and Promise.allSettled() for concurrent execution. Results from all 20 platforms arrive in parallel, not sequentially.
Official APIs (highest confidence)
Where platforms offer a free official API that works from datacenter IPs, we use it as the primary check:
- YouTube — YouTube Data API v3
channels?forHandle=. Returns channel ID if the handle exists, empty if it does not. An “available” API verdict is cross-checked with a HEAD request to guard against a known Google API quirk where real channels occasionally return empty results. - Twitch — Twitch Helix API
/helix/users?login=with a client-credentials app token (no user auth required). Emptydataarray means the login does not exist. App tokens are cached per isolate and refreshed on 401. - Kick — Kick official API
/public/v1/channels?slug=with a client-credentials app token. Kick's unofficial endpoints are Cloudflare TLS-fingerprint-gated and not usable from Workers; the official API is the only viable edge-compatible path. - GitHub — GitHub REST API
/users/{username}. A 404 is the API saying the user does not exist; 200 means it is taken.
HTTP/status-and-content analysis (most platforms)
For platforms without a free, edge-usable official API, we make direct HTTP requests — a HEAD or GET — and analyze the response: HTTP status code, redirect destination, and where appropriate, page content or structured data (JSON-LD, oEmbed, og:title). Each platform has its own checker with documented signal logic:
- Reddit — JSON API endpoint
/user/{name}/about.json. A 404 from the JSON API is highly reliable. - Telegram — GET on
t.me/{name}with page-content pattern matching for presence/absence indicators. - TikTok — TikTok oEmbed endpoint (no bot detection, returns JSON), with HEAD fallback. Confidence is capped at 0.85 because TikTok's datacenter-IP responses are less consistent than a true API.
- Instagram — Instagram web profile info endpoint, with HTML og:title fallback. Login-wall redirects are detected and recorded as low-confidence, not as a false “available.”
- Twitter/X — Twitter syndication timeline endpoint (no auth required), with HEAD fallback on x.com.
- Bluesky, Threads, Pinterest, Snapchat, Mastodon, Product Hunt, LinkedIn, npm, Substack, Linktree, Roblox — Platform-specific HTTP checkers using status codes and redirect analysis, each with tuned confidence constants reflecting the reliability of that platform's response patterns.
Social-data API fallback (paid users, hard platforms)
Instagram, TikTok, and Twitter/X are the hardest platforms to check reliably from datacenter IPs — they aggressively redirect to login pages, return bot-detection responses, or obscure profile existence. When a paid user runs a check and the HTTP result comes back with confidence below 0.75, we escalate to a third-party social-data API that proxies the request through residential IP infrastructure and returns a structured verdict from the response body (not the HTTP status, since these APIs always return 200). The escalation is a confirmation step, not the primary check: we only spend a paid API call when the free HTTP check is ambiguous. If the API returns a lower-confidence result than our HTTP check, we keep the HTTP result.
The social-data processor is a third-party service. We disclose this in our Privacy Policy. We pass only the handle string (no account information). 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: RDAP 404. For social: YouTube Data API, Twitch Helix, GitHub REST API, or Reddit JSON endpoint returning a clean 404. 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 andnon-existing profiles. Twitter/X may return a 200 with login-wall content regardless of whether the handle exists. LinkedIn uses HTTP 999 for bot detection. 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.
LinkedIn in particular shows low confidence (30–85%) because every logged-out request is either walled or returns a 999. We include it because partial information is more useful than silence, but we make the uncertainty explicit.
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 separate Cloudflare scheduler Worker fires a cron trigger and posts to the monitoring endpoint every 15 minutes. Your plan determines how often your specific watches are re-checked (Free: 12-hour frequency; Pro: 1-hour; Business: 15-minute). The poller processes watches in concurrent batches — it does not run them serially — and leases each batch atomically before processing so that two overlapping runs cannot double-check or double-alert the same watch.
Detect cheap, confirm expensive
Every poll starts with the free HTTP check. Paid API calls (the social-data API escalation) are spent only when the HTTP check returns a suspected taken → available transition with low confidence. This keeps monitoring costs proportionate to the event rate: normal polls that confirm a handle is still taken cost nothing beyond compute; ambiguous or transitioning handles trigger a more expensive confirmation step. The alternative — calling a paid API on every poll for every watch — would be roughly 100× more expensive and provide no better result for the 99% of polls that see no change.
Confirm before alerting
A single poll showing a handle as “available” is not enough to send an alert. Platforms routinely return 404s for handles that are reserved, temporarily suspended, in a post-deletion hold period, or hitting bot-detection logic. We require at least two consecutive high-confidence polls (confidence ≥ 0.85) before flipping a watch from “taken” to “available” and sending a notification.
Conversely, a confident “taken” verdict commits immediately — the dangerous direction for false positives is available, not taken. Error and uncertain polls never change a watch's recorded status. Notifications are throttled: at most one external alert per watch per 24-hour window, regardless of how many polls run.
Our Data Sources
Where each type of information comes from, and how third-party services are disclosed.
Domain availability
- Cloudflare DoH / Google DoH — DNS-over-HTTPS resolvers queried directly for NS records (Tier 1 fast-path).
- IANA RDAP bootstrap + registry RDAP endpoints — Free, authoritative registration data served by the domain registries themselves. No third-party markup. (Tier 2)
- WhoAPI — Paid fallback, only for ccTLDs that lack a public RDAP endpoint, and only when a key is configured. (Tier 3)
Social handle availability
- Official platform APIs — YouTube Data API, Twitch Helix, Kick official API, GitHub REST API. Free, no third-party intermediary.
- Direct HTTP / platform endpoints — Public-facing endpoints and oEmbed APIs queried directly from our infrastructure for all other platforms.
- Third-party social-data API — Used as a paid-user confirmation fallback for Instagram, TikTok, and Twitter/X only. We pass the handle string; we receive and store only the availability verdict. This processor is disclosed in our Privacy Policy.
Trademark screening
USPTO trademark data via MarkerAPI (9M+ live trademark records, free tier). When credentials are not configured, 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.
RDAP endpoint mappings are cached for 24 hours and re-fetched from the IANA bootstrap, so we track registry-level changes automatically. Official API checkers (YouTube, Twitch, Kick) are updated when those APIs 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 Cloudflare datacenter IPs. Instagram, TikTok, Twitter/X, and LinkedIn all serve different responses to datacenter IPs than to residential ones — including presenting login walls for handles that do and don't exist alike. The social-data API escalation mitigates this for paid users, but even that is a proxy and 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.
Rate limits and single-instance rate enforcement
Platform APIs and endpoints impose rate limits. Our rate limiting logic runs in-memory within a single Cloudflare Worker isolate; under high load across multiple isolates, limits may not be enforced uniformly. This is a known limitation of the single-process rate limiting model and does not affect result accuracy, but it means the "3 checks per day" guest limit is a best-effort cap rather than a hard one.
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.