Changelog

All notable changes to IPBot are documented here. The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[1.9.0] - 2026-06-30

Added

• POST /v1/crawler/verify — a narrow crawler-verification endpoint for site-owner workflows. Given an ip and optional user_agent, it returns a verification_status of verified, known_unverified, or not_known, plus crawler classification (crawler_provider, crawler_type, crawler_verified_by, crawler_hostname), public network owner/allocation context, and an explanation with a machine-stable reason_code. DNS-verifiable families (Googlebot, Bingbot) can reach verified from the IP alone via reverse+forward DNS; OpenAI-family crawlers require both official range membership and a matching crawler user-agent token, otherwise they stay known_unverified (reason_code: user_agent_mismatch). Documented in docs/openapi.v1.yaml.
• Crawler verification tool and hub on the site: a /crawler-verify interactive tool (URL round-tripping, presets, accessible status), a /crawlers hub, and per-crawler /crawlers/{slug} detail pages backed by a versioned crawler catalog.

Changed

• The main IP lookup and the new endpoint now share one crawler-verification code path (resolveCrawlerVerification), so classification.is_verified_crawler / crawler_verified_by semantics are identical across both surfaces. Public score.risk_score, score.verdict, and score.recommended_action are unchanged.

[1.8.1] - 2026-06-28

Changed

• Decision-engine scenarios.*.action is now chosen by expected loss (§8) instead of a static role×scenario table: each surface (content, seo_crawler, login, signup, payment, api) picks the action with the lowest combined cost of being wrong, given the IP’s evidence and that scenario’s stakes. Friction is now evidence-driven and proportionate — a clean IP gets no friction on any surface, while anonymizing/abusive IPs get graduated friction that rises on higher-stakes surfaces. Role floors are also enforced as true minimums (e.g. a Tor exit is at least challenge on every scenario).
• scenarios.*.confidence is now computed per scenario (from each scenario’s expected-loss margin) rather than reusing the top-level decision.confidence.
• These are additive decision-engine fields. Public score.risk_score, score.verdict, and score.recommended_action are unchanged.

[1.8.0] - 2026-06-27

Changed

• Public risk_score is now computed by the source-tier scoring model. It weights each piece of evidence by the authority of its source (official > registry/routing > commercial > community > heuristic). In practice this reduces false positives on trusted infrastructure — public DNS resolvers, verified crawlers, CDN/edge nodes, and Apple Private Relay sitting on generic datacenter ASNs now score lower (e.g. 8.8.8.8 30 → 12, 1.1.1.1 25 → 10) — and dampens heuristic-only signals, while strong threat, Tor, routing-conflict, and commercial-fraud signals are preserved or strengthened (e.g. a Tor exit stays at its full score; a BGP origin conflict scores higher).
• score.verdict thresholds are unchanged; most affected IPs move lower within the same verdict band, and any verdict shifts are toward less friction (e.g. monitor → allow) on genuinely trusted infrastructure. Two IPs with identical evidence still receive an identical score.
• This was validated against a promotion gate (zero regressions, zero needs-review cases) before rollout and is reversible. Clients reading score.risk_score/score.verdict should expect slightly lower scores for trusted-infrastructure IPs.

[1.7.1] - 2026-06-26

Changed

• decision.confidence (and each scenarios.*.confidence) is now calculated from a multi-factor model — evidence quality, decision margin (how far the score sits from an action boundary), source authority, contradiction between trust and adverse risk signals, and guardrail stability — instead of a single evidence-quality threshold. Infrastructure context is not treated as adverse by itself. Same schema and low/medium/high values; the levels are simply more accurate.
• The decision policy identifier is now decision-v1-2026-06.2. Admin-only GET /v1/internal/score/{ip} responses include trace.decision_confidence with the confidence score and component breakdown; public /v1/ip/* responses continue to expose only the low / medium / high confidence enum.
• In v1, scenarios.*.confidence reuses the top-level decision.confidence; per-scenario confidence is not independently computed.
• explanation.drivers[].impact_score is now a true leave-one-out counterfactual (each signal’s marginal effect), so redundant signals in an already-saturated group correctly show a small impact instead of their raw probability.

These remain purely advisory. Public score.risk_score, score.verdict, and score.recommended_action are unchanged.

[1.7.0] - 2026-06-23

Added

• Decision Engine v1: four additive, optional top-level objects on v1 IP lookup responses — decision (profile/role/action/risk_level/confidence/policy_version/allowed_actions/blocked_actions/guardrails_applied), scores (eight 0-100 component sub-scores: risk, base risk, abuse, anonymity, trust, infrastructure, routing risk, evidence quality), scenarios (per-scenario action/risk_level/confidence/reason for content, seo_crawler, login, signup, payment, api), and explanation (summary, key_reason, drivers with direction and impact, guardrails_applied, reason_chain).
• decision, scores, scenarios, and explanation projection support via fields=.
• Decision panel in the web IP Lookup tool surfacing role, action, sub-scores, scenarios, and explanation.

Changed

• These fields are purely advisory. Public score.risk_score, score.verdict, and score.recommended_action are unchanged, and clients that ignore the new fields keep working exactly as before.

[1.6.0] - 2026-06-18

Changed

• score.risk_score now combines signals with a bounded noisy-OR (probabilistic OR) instead of an additive sum-and-clamp. Scores are calibrated and continuous, multiple risk signals no longer pile up at exactly 100, and single-signal scores are unchanged. Two IPs with identical evidence still receive an identical score by design.
• score.verdict thresholds are re-aligned to the public bands so the verdict never contradicts the displayed band: block at risk_score ≥ 61 (danger), challenge at ≥ 41 (poor), monitor at ≥ 31 (fair), otherwise allow.

Added

• Commercial IP2Proxy fraud scores fold into risk_score as a continuous, bounded probability (replacing fixed buckets); no effect on lite data.
• GET /health returns a build block (git_sha, build_time, risk_model_version, verdict_threshold_version, rules_version, data_edition), and every response carries an X-IPBot-Build header, so a deployed build is machine-verifiable.
• Prometheus ipbot_scoring_risk_score histogram and ipbot_scoring_verdicts_total{verdict,band} counter for score-distribution and verdict-mix drift detection.
• Admin-only GET /v1/internal/score/{ip} scoring trace: every contributing signal with its probability, suppressions, trust dampening, and the noisy-OR result. Never exposed in public or legacy responses.
• Optional range-reputation signal (IPBOT_RANGE_REPUTATION_ENABLED, default off): a bounded /24 neighbor-abuse-density estimate computed from existing threat data.

[1.5.0] - 2026-06-09

Added

• Pro-only include=rdap_contacts for GET /v1/ip/current and GET /v1/ip/{ip}, returning normalized RDAP network/contact data only after Pro API key authentication.
• fields=rdap projection support when the Pro RDAP include is accepted.
• Normalized RDAP contacts, addresses, phones, emails, notices, remarks, and redaction metadata in the ownership cache without storing raw RDAP JSON or raw WHOIS text.

Changed

• Free and anonymous lookup responses continue to expose only network.owner and network.allocation; RDAP contact details remain hidden unless explicitly requested by a Pro key.

[1.4.0] - 2026-05-22

Added

• Evidence-first IP intelligence stack with public proxy, provider, Apple Private Relay, verified crawler, threat, and ASN context.
• /v1/data/status endpoint for public service and capability readiness.
• Internal Prometheus counters for lookup volume, signal hit rate, proxy type distribution, residential hits, commercial-field coverage, and conflict/shadow-diff tracking.
• Tracked OpenAPI v1 contract at docs/openapi.v1.yaml.
• OpenClaw release smoke support for API Docker smoke and API + Astro preview validation.

Changed

• Proxy detection is now presented as evidence fusion rather than a single-vendor wrapper.
• Conservative confidence is used when residential/provider/fraud-score evidence is not strong enough for public claims.
• Verified crawler and Apple Private Relay evidence protect those classes from being treated as ordinary high-risk proxy abuse.
• Data update scripts preserve last-known-good files on download failure and avoid replacing netintel-ranges.jsonl until normalization succeeds.

[1.3.0] - 2026-01-08

Added

• ASN Insights enrichment data integrated into IP lookup responses
• Skeleton loader for improved perceived loading performance on web tools

Changed

• Rebranded Radar feature to ASN Insights across all documentation and UI
• Cache metadata hidden from user-facing responses for cleaner output

[1.2.0] - 2026-01-08

Added

• API key authentication system for enhanced access control
• Rate limiting with configurable tiers per API key
• ASN context from Radar-backed enrichment in IP lookup responses

[1.1.0] - 2026-01-07

Changed

• Migrated documentation to standalone pages for better SEO
• Updated branding across all web pages

[1.0.2] - 2026-01-06

Fixed

• API response parsing for nested ASN structure in Radar data

[1.0.1] - 2026-01-05

Added

• ASN-based risk scoring layer with keyword matching
• Redis-backed L2 cache for Radar enrichment data
• Blog infrastructure for content publishing
• Enhanced landing page with interactive demos

Changed

• Improved documentation with code examples
• Enhanced frontend performance and UX

[1.0.0] - 2026-01-04

Added

• Initial release of IPBot IP Intelligence API
• IP geolocation with country, region, city, and coordinates
• ASN and organization lookup
• Threat intelligence with risk scoring
• Explainable risk reasons for auditability
• CORS-enabled endpoints for browser usage
• No API key required for free tier
• Health check endpoint with data version info
• Hot-reload support for configuration updates