Choose a plan for the API you need

Each authenticated call that passes your key and origin checks counts as one request: a visitor geolocation call, each IP looked up, each email address checked, each signup check and each impossible-travel check. A call that then fails input validation still counts. Calls rejected for a missing or invalid key, a disallowed origin or the per-minute rate limit don't count, and neither do deleting a risk baseline or polling an email list job.

It's a fixed one-minute window, aligned to the clock minute — not a rolling average. On the Free plan you can make up to 30 requests between, say, 10:32:00 and 10:32:59; the counter resets to zero at 10:33:00. Going over returns an HTTP 429 with a Retry-After header telling you how many seconds until the window resets. It's independent from your monthly request volume below — it caps burst rate, not total usage. The limit counts API calls, not items: a batch of up to 100 IPs or email addresses, or creating an email list job, is one request toward it — while each IP or address in it still counts separately toward your monthly request volume.

Requests are rejected in real time once your plan's monthly cap is reached — you'll get a 429 with error: "monthly_limit_exceeded" until the next monthly window starts or you upgrade. We email you at 75%, 90%, and 100% of your cap so this shouldn't be a surprise. If you're consistently running close to the limit, upgrade any time from your dashboard — no code or API key changes needed.

Visitor geolocation reads edge request data and derives regional enrichment locally, which keeps its cost — and price — well under most providers' equivalent tiers. Server-side IP lookup is bundled into the same plan and price rather than sold separately: each plan includes both a request cap and an IP lookup allowance drawn from that plan's shared monthly pool.

Visitor geolocation and IP lookup responses include regional enrichment where source data is available. Eligible plans also include list-based security indicators. Email checks return a separate, domain-level result. Latency varies by request and enabled features.

Yes. GET /v1/geo remains visitor self-lookup only, resolving the IP that's actually connecting, client-side. For arbitrary-IP lookup, GET /v1/lookup/{ip} (single) and POST /v1/lookup (batch, up to 100 IPs per call) are server-to-server endpoints authenticated with a secret key instead of your publishable one — the key stays on your backend and is never shipped to a browser. Both are backed by a third-party IP geolocation database rather than our own real-time network data, with a different response shape and no verified relative-accuracy ranking — see data sources for the specific provider and required attribution — and usage is priced per IP looked up, drawn from your plan's shared monthly pool 1-for-1 with a geo request (see your plan's IP lookup allowance above for the separate cap on total lookups). Because this endpoint looks up IPs your customer supplies rather than the visitor calling on their own behalf, it makes Watch-IP a processor of that third-party data on your behalf — see the DPA for what that means for your own compliance obligations.

POST /v1/risk/check compares a supplied IP’s third-party-resolved location with a stored user baseline and returns low/medium/high risk and an impossibleTravel flag. It uses a backend Bearer secret key — the same secret key you already use for IP lookup, on the same plan. There's no separate risk plan or price: each check counts as one request against your existing plan's monthly cap. You can also delete a stored baseline at any time via DELETE /v1/risk/baseline. VPN changes and mobile routing can cause false positives.

Yes. POST /v1/email/validate uses a publishable, origin-locked key to check syntax, known disposable domains, whether the domain has a mail server, likely typos and role addresses, and returns an accept, review or reject verdict with reasons. From your backend, POST /v1/email/batch checks up to 100 addresses per call, list jobs handle up to 100,000, and POST /v1/signup/check adds the signing-up IP's network signals. Each checked address counts as one request against your plan's monthly cap (a list job charges each distinct address once). None of these contact the mailbox, so they do not verify mailbox existence, ownership or deliverability.

It depends on the key type. Publishable keys — used for GET /v1/geo and POST /v1/email/validate — are meant to ship in page source, like a Stripe or Google Maps publishable key; the access control is origin-locking: each key only works from the domains you register, and CORS is only granted to a matching origin. Secret keys — used for IP lookup, bulk email, signup and impossible-travel checks — must stay on your backend and never appear in browser code.

SDK source packages exist for JavaScript/TypeScript, Python, PHP, Go, and Flutter/Dart. Verify registry availability and endpoint support before use. GET /v1/geo always locates the connecting caller; a backend call does not locate your website visitor. Use secret-key lookup for a supplied IP.

Yes, but it's opt-in: add ?include=hostname to the request (or include: ["hostname"] in the SDK) and the response gains a hostname field, resolved via a DNS-over-HTTPS PTR lookup. It's null when there's no PTR record. Unlike the always-on enrichment fields above, this does a real network lookup inside the request, so it's left off by default rather than adding latency to every call.

Eligible plans include list-based isVpn, isTor, isDatacenter, isThreat, and isSanctionedNetwork flags on both visitor geolocation and IP lookup responses; Free omits security. IPv4 supports list and ASN matching. IPv6 supports VPN, datacenter and threat ranges plus ASN matching, but has no Tor coverage. Production coverage depends on available feeds. False means no match in available data, not a guarantee of safety; these signals are not definitive sanctions screening.

Yes — every response includes a compliance object: isGDPR (EU/EEA + UK), usPrivacyLaw (the applicable US state law, e.g. CCPA/CPRA or VCDPA, keyed off the visitor's state), isLGPD (Brazil), a derived requiresCookieConsent flag, a coarse dataResidencyZone, and isEmbargoedCountry (OFAC comprehensive country embargoes). It's included at no extra cost on every plan, the same as currency and calling code. It's a first-pass jurisdiction signal computed from the visitor's location, not legal advice — always confirm compliance requirements with your own counsel.

Yes — every response includes a locale object: suggestedLocale is a BCP47 locale that combines the visitor's country with their browser's own Accept-Language header, preferring a language actually spoken there (e.g. an Accept-Language of "fr" from a Canadian visitor yields "fr-CA", not "fr-FR"), falling back to the country's default locale when nothing in the header matches. The same object also includes measurementSystem (metric/imperial), firstDayOfWeek, and dateFormat, so you don't have to re-derive regional formatting conventions yourself. It's included at no extra cost on every plan.

Yes — every response includes a holiday object: isPublicHolidayToday, todayHolidayName, and nextHoliday (date and name) for the visitor's country, computed from a curated static table (currently ~40 countries — G20 + the EU/EEA + UK) sourced from Nager.Date and refreshed on a manual, once-or-twice-a-year cadence rather than a request-time computation. It's null for countries outside that list, and only counts nationwide public holidays, not state/province-only observances. Included at no extra cost on every plan; more countries are addable on request.

Static mappings provide age and jurisdiction hints based on approximate IP location. They do not verify identity or age; confirm applicable requirements independently.