Summary

  • ICANN says its Open Data Platform and API will be unavailable from 1 September. The replacement lets anyone download the available CSV files without logging in, while users who depended on the old platform must update their processes.
  • The transition should be measured with two separate tests: access to current files and continuity of dataset identity. A public crosswalk and release receipt would show where each former dataset went and which exact bytes, definitions and correction state support later analysis.

At midnight between 31 August and 1 September, two things will become true at once. A visitor will no longer need an account to download the CSV files ICANN presents on its new Open Data Initiative pages. A program built against the old Open Data Platform API will no longer have that interface.

The first fact is an improvement. The second is a capability change. Treating either as the entire story would obscure the governance work in the handoff.

ICANN announced the new page on 15 June and kept the old platform available through the end of August so users could explore the replacement and update their processes. On 27 August, it issued a final reminder: after 31 August the platform will be unavailable; from 1 September its API will also be unavailable; the old URL will redirect to the new landing page. ICANN says the move simplifies public access and reduces maintenance, storage and backup requirements.

That is clear notice, not a concealed shutdown. It is also narrower than a continuity record. The announcements tell users where to begin again. They do not, on the pages reviewed for this article, join every former catalogue identity, API dependency and dataset capability to an attributable current disposition.

One access barrier falls

The current landing page names two data families: Domain Name Marketplace Indicators, or DNMI, and Security Response Waiver Requests, or SRW. The links lead to ordinary downloadable files rather than an account gate.

DNMI's Version 1.1 measurement structure has 16 active indicators across Robust Competition, Marketplace Stability and Consumer Trust. The category pages label active files as annually updated and retain older indicators in clearly marked archive sections. The SRW page publishes one annual file covering five measures, including requests received, gTLDs and domains affected, timing of requests, and waiver dispositions.

That design has real strengths. A complete CSV is easy to save, inspect with common tools and process without a vendor-specific client. A researcher can keep a local copy. A journalist can examine the columns. A small operator does not need an account, API key or quota merely to fetch the public file.

The two sample files checked for this article were reachable. Their responses included ordinary delivery metadata such as Last-Modified and ETag. Those observations show working file delivery at the cutoff. They do not prove a permanent file identity or an institutional correction history, and this article makes no claim that either file is inaccurate.

The distinction matters because access answers a limited question: can a user fetch the file now? Reproducibility asks a longer one: what exact release did the user fetch, what period and definition governed it, and what later record corrected or replaced it?

The old platform was more than a download button

ICANN's 2018 procurement notice described a more ambitious public-data role. The planned platform would publish data with open licensing and open API access. It would provide reliable machine-readable material for download and processing and serve as a source system for people in ICANN org and the community producing analysis.

The former platform's own About page extended that promise. It said data should be accessible and usable, timely and comprehensive, comparable and interoperable, and useful for governance and community engagement. Registered functions included saved analyses, update notifications, API keys and quota visibility.

Not every one of those functions has to survive in the same product. A separately hosted vendor platform has costs, and an institution can legitimately simplify its technology. An API is not a moral property. Nor is a CSV intrinsically second-rate: for full snapshots, a simple file can be more portable than a query whose parameters and server behaviour are difficult to reconstruct.

But the interface choice changes what users must preserve themselves. API users may have relied on a dataset identifier, filters, query fields, pagination, notification or a machine-readable catalogue. File users need a stable way to distinguish releases and determine whether a same-path object is unchanged, corrected or newly issued. Retiring the platform is defensible; retiring its institutional memory by accident would not be.

Four former catalogue themes do not map visibly onto two current rows

The former homepage visibly grouped data under four themes: DNMI, Identifier Technology Health Indicators, Registry Activity Reports and Registrar Transaction Reports. The current Open Data landing page visibly lists DNMI and SRW and says more datasets will be added as they become available.

That four-to-two comparison is not evidence that two families vanished. Monthly Registry Reports are currently reachable on a separate ICANN page, organised by top-level domain. The ITHI dashboard is also reachable and displays current and historical identifier-health measurements. The correct conclusion is more modest: the landing pages alone do not supply a one-row-per-former-family crosswalk.

That matters because ICANN previously moved Registry Functions Activity Reports and Per-Registrar Transactions Reports in the opposite direction. In 2021 it told users of automated scripts to change those scripts to use the Open Data API. A user who followed that instruction now has to change again. The present notice says to update processes, but a durable public record should say what each old dependency becomes.

A map might state that one family moved to the new CSV page, another remains on a dedicated research dashboard, another returned to a main-site report archive, and a particular API capability has no equivalent. None of those outcomes is inherently a failure. Ambiguity about which outcome applies is the problem.

A redirect preserves navigation, not evidence identity

The planned redirect is useful for a person who visits the old homepage. It cannot encode the full meaning of a former dataset or query.

Suppose an analysis cites “RC 2.1” and the URL of the current CSV. A later reader still needs to know which release was used, the coverage period, the governing measurement definition, the expected file digest, the row count and whether a correction superseded it. A web server's timestamp or entity tag can help with caching and change detection. Unless the publisher defines it as such, it is not the public decision record that explains why the bytes changed.

This is not a demand for an elaborate new platform. The thinnest sufficient layer is a public transition concordance joined to a release ledger.

Public field Question it answers
Former family, dataset identifier and API route What dependency is being migrated?
Current canonical location and accountable owner Where is it now, and who maintains it?
Disposition and capability delta Was it migrated, retained elsewhere, merged, archived or ended—and what changed?
Coverage, cadence and definition version What period and measurement rules do the values represent?
Release time, expected digest and row count Which exact public object is the release?
Correction and supersession links What changed later without rewriting the earlier record?
License, aggregation constraints and contact What may users do, what boundaries apply, and where can they challenge an error?

The concordance would keep navigation and authority separate. A destination URL says where an object can be obtained. A release receipt says which object the institution stands behind for a defined purpose and period. A correction link says how the public record changed without pretending the earlier release never existed.

Open data needs portable memory

ICANN's simplification lowers an immediate barrier: no-login downloads are better than making a reader create an account to obtain an available public file. Cost reduction can also be a legitimate operational choice. The relevant accountability test is not whether the old vendor survives.

It is whether the public evidence survives the vendor.

A thin portable record would make future interface changes cheaper. A dataset could move from an API to CSV, from one host to another or into a research dashboard without losing its identity. Users could update software against an explicit disposition instead of reconstructing the migration from pages and redirects. Analysts could cite an immutable release identity rather than a file that happens to occupy a URL today.

ICANN has already given users a date, a destination and a broad reason. The remaining opportunity is to give the handoff its receipt. That would turn a platform retirement into a verifiable continuity event—and make the next migration less dependent on institutional memory living inside an interface that may itself be temporary.

Sources

  1. ICANN Public Data Webpage Update, 27 August 2026
  2. ICANN Releases New Public Data Webpage, 15 June 2026
  3. ICANN Open Data Initiative
  4. Domain Name Marketplace Indicators
  5. DNMI: Robust Competition
  6. DNMI: Marketplace Stability
  7. DNMI: Consumer Trust
  8. Security Response Waiver Requests
  9. Former Open Data Platform homepage
  10. Former Open Data Platform About page
  11. ICANN's 2018 Open Data Platform procurement announcement
  12. ICANN's 2021 registry-report migration announcement
  13. Current ICANN Monthly Registry Reports
  14. Current ITHI dashboard
  15. Sample DNMI RC 2.1 CSV
  16. Sample SRW M1-M5 CSV