Watch-IP data sources and coverage

Every field in a Watch-IP response comes from one of two sources, depending on the endpoint: our own network-level data for the connecting browser (GET /v1/geo), or the third-party DB-IP City Lite and ASN Lite databases for a supplied IP address (GET/POST /v1/lookup). Both endpoints compute the same currency/compliance/locale/sun/holiday/age/tax fields from whichever location their source provides. The email check has its own sources, described below. This page states which source backs which field, what's missing, and how to report a suspected error — see accuracy for how to evaluate either source yourself.

GET /v1/geo: network-level data plus local enrichment

country, region, regionCode, city, latitude, longitude, continent, postalCode, timezone, asn, and asOrganization come from our own request-level network data for the connecting client — read fresh on every request, not from a separate database Watch-IP maintains. currency, callingCode, locale, sun (sunrise/sunset), holiday, age, tax, and compliance fields are computed locally from that location plus maintained reference tables bundled with the API; they are regional hints, not independently observed facts about the visitor. security (VPN/Tor/datacenter/threat/sanctioned-network indicators) is matched against list data described below, and only appears on plans that include it.

GET/POST /v1/lookup: DB-IP City Lite and ASN Lite

ip, found, country, continent, regionCode, city, latitude, and longitude for a supplied address come from DB-IP's City Lite database; asn and asOrganization come from DB-IP's separate ASN Lite database. region (the subdivision name, as opposed to regionCode) is resolved from a static GeoNames admin1 table keyed on country+regionCode. postalCode — City Lite has no postal field at all — is resolved from a separately compiled GeoNames postal-code index keyed on country+coordinates, with AI-assisted disambiguation for areas with multiple ambiguous candidate postal codes, precomputed on a monthly refresh rather than per request; both region and postalCode are null outside GeoNames' own coverage (partial in several countries). timezone is computed from latitude/longitude rather than read from either database, since neither has a timezone field. currency, callingCode, locale, sun, holiday, age, tax, compliance, and (on plans that include it) security are computed the same way GET /v1/geo computes them, just from this endpoint's own country/regionCode/coordinates — locale's suggestedLocale is always just the country's default here, since there's no browser Accept-Language header on a server-to-server call. userAgent and hostname are both opt-in and only available on the single-IP route (userAgent because you supply it yourself; hostname via ?include=hostname). found: false means no matching record for the address in the currently loaded database; the same implementation can also return found: false if the database itself is unavailable or hasn't finished loading, so treat false as “no usable result,” not proof the address has no real-world location.

Source: DB-IP (db-ip.com) — City Lite and ASN Lite editions.
Attribution: IP Geolocation by DB-IP (db-ip.com), per DB-IP's license terms for these editions.
Update cadence: Set by DB-IP's own release schedule for City Lite/ASN Lite; Watch-IP does not independently verify per-record freshness.

Security list coverage differs by network type and IP version

The isTor, isVpn, isDatacenter, isThreat, and isSanctionedNetwork fields are matched against separately maintained lists, not derived from our own network-level data or DB-IP. IPv4 connections are checked against all five categories; IPv6 connections are checked against everything except Tor, since there's currently no free IPv6 Tor exit-list source — isTor is always false for an IPv6 connection regardless of whether it's actually a Tor exit. These lists are compiled and stored in our own storage and refreshed on a schedule; a slow or failed refresh degrades to stale or empty list data rather than a broken response, so a false result means “no match in the currently loaded list,” never a verified-clean connection.

Email check: disposable-domain lists, DNS and registration data

isDisposable is matched against a merged list of three community-maintained open-source disposable-domain lists, refreshed every few hours, minus a built-in allowlist of major mailbox providers and corporate domains so a bad upstream entry can't flag them; subdomains of a listed domain match too. disposableSource: mx_host comes from Watch-IP's own observation of which mail servers the listed domains use — a mail host that serves several listed domains, and isn't a shared mail provider, is treated as disposable. mx is a live DNS lookup (DNS-over-HTTPS) cached for up to a day; a failed or slow lookup is reported as unknown rather than guessed. isFreeProvider, isRoleAccount and didYouMean come from curated tables maintained by Watch-IP. emailDomainAgeDays (signup check only) comes from public domain-registration data via RDAP, cached for 7 days, and is null wherever a registry doesn't publish it. No source is consulted about the individual mailbox.

disposable-email-domains: github.com/disposable-email-domains/disposable-email-domains — CC0 / public domain.
disposable/disposable-email-domains: github.com/disposable/disposable-email-domains — MIT license.
FakeFilter: github.com/7c/fakefilter — BSD-3-Clause license.
Update cadence: Lists are re-fetched every few hours; a failed or truncated upstream download keeps the last good list instead of shrinking it.

Observed versus computed values

Treat country/region/city/coordinates/ASN as the closest thing to an observed value — read directly from our own network-level data or DB-IP's databases for that specific request or address. Treat currency, calling code, locale, sunrise/sunset, holiday, age, tax, and compliance fields as computed hints derived from that location plus static reference tables — the same computation on both GET /v1/geo and GET/POST /v1/lookup: useful as defaults, not as independently verified facts about the person or address behind the connection.

If you find a suspected error

Contact us with the specific IP or request and what you expected — we can check whether it's a known limitation described on this page, a stale list entry, or something to follow up on with DB-IP about. Watch-IP doesn't control DB-IP's underlying database and can't guarantee a correction timeline for it, but we do track and report back on issues raised this way.