ROR’s Version-1 API and Schema Sunset (Dec 2025): What Institutions Need to Know

The Research Organization Registry (ROR) retired version 1 of its API and metadata schema in December 2025, capping an 18-month migration window that started when ROR schema v2.0 went into production in April 2024. For most institutions this was invisible — ROR’s own hosted search and record pages moved automatically — but any integration that called the ROR API directly, or that parsed the ROR data dump programmatically, needed to have moved to v2 before the cutover or it broke. Here is what actually changed, when, and what to check if your institution has a ROR-consuming tool anywhere in its stack.

The timeline

ROR set out the sunset schedule in a blog post published 11 June 2025, then reiterated it in the changelog on 1 July 2025. Two dates matter:

• Week of 28 July 2025: unversioned API calls (requests to api.ror.org with no /v1/ or /v2/ segment in the path) started defaulting to v2 instead of v1. Anyone who had built against the API without pinning a version number was switched over at this point, whether they had tested for it or not. Requests that explicitly specified /v1/ in the path kept working through this date.
• Week of 8 December 2025: v1 of the API and v1 of the schema were switched off entirely. Explicit /v1/ requests now return an HTTP 410 (Gone) rather than data. ROR’s data dumps on Zenodo also stopped shipping v1-schema CSV/JSON files from that point forward — release 1.75 onward is v2-schema only.

ROR’s own changelog noted that a small minority of API traffic — the organization has put the figure at under 8% of requests — was still explicitly targeting v1 by the time of the December cutover, so the practical blast radius was real but not universal. If your tooling was already unversioned or already on v2, this sunset changed nothing for you.

What actually changed between schema v1 and v2

ROR schema v2.0 was designed and shipped in April 2024 specifically to correct structural debt inherited from GRID, the Digital Science database ROR was originally built from in 2019 (see CASRAI’s ROR/ISNI/Ringgold/GRID crosswalk for that lineage). The changes that matter for anyone parsing ROR records directly:

• Names consolidated into one array. v1 spread an organization’s identity across four separate fields — name, aliases, labels, and acronyms. v2 merges all of these into a single names array, where each entry carries a value, a language code, and a type (including a new ror_display type marking the organization’s canonical display name). Code that reads record.name directly will not work against a v2 response.
• Addresses replaced with a simpler locations array. v1’s addresses field carried a long list of largely-empty GeoNames sub-fields. v2 replaces it with a locations array holding a GeoNames ID plus the fields that were actually populated in practice (coordinates, country code, city name).
• External identifiers restructured. v1 exposed identifiers like ISNI, FundRef, Wikidata, and GRID as separate named fields under external_ids. v2 turns external_ids into an array of objects, each carrying its own type, which is why ROR was able to add and deprecate identifier schemes (OrgRef was dropped) without another breaking schema change.
• New admin and domains fields. v2 adds an admin block recording creation/modification timestamps and schema version per record — useful for anyone doing incremental syncs against the data dump — and a domains field capturing an organization’s registered web domain separately from full URLs.
• Deprecated fields dropped. email_address and ip_addresses, both already empty or null in v1 records, were removed outright in v2 rather than carried forward.

None of this changes what a ROR ID identifies or how it resolves — a ROR identifier minted under v1 metadata is the same identifier under v2, and existing ROR IDs embedded in CRIS records, DMPs, or manuscript metadata did not need to change. What changed is the shape of the record you get back when you query the API or read the data dump, and code written against the old shape needs updating.

Who this actually affects

The people who needed to act before December 2025 fall into a narrow but real set:

• Institutions or vendors running a custom integration against the ROR API — a CRIS, an institutional repository, a grants system, or an internal tool that queries api.ror.org directly to look up or validate organization records, rather than going through a vendor-maintained connector.
• Anyone consuming the ROR data dump programmatically — for bulk matching, deduplication, or building a local mirror of organization identifiers — needs code that reads the v2 field names (names, locations, restructured external_ids) rather than the v1 equivalents.
• Tool vendors whose ROR integration sits behind an institution’s DMP, repository, or CRIS platform — here the responsibility sits with the vendor, but it is reasonable for a research office to ask its DMPTool, repository, or CRIS provider to confirm they had already migrated to v2 well ahead of the December cutover.

Most research administrators never call the ROR API directly — they encounter ROR IDs through a DMP tool’s auto-fill (see CASRAI’s DMPTool ROR auto-fill guide), a funder’s application portal, or a CRIS’s institution-lookup field. For that majority, this sunset was a vendor-side event with no visible change on the front end. The exposure is specific to anyone maintaining custom code against the raw API or data dump.

What to check now

• Grep any internal codebase, script, or ETL job for api.ror.org and confirm the request path includes /v2/, not /v1/ and not an unversioned path assumed to still mean v1.
• If a request is still hard-coded to /v1/, it has been returning HTTP 410 since the week of 8 December 2025 and needs to be updated, not just monitored.
• If code parses ROR data-dump files directly, confirm it reads v2 field names (names/locations/array-style external_ids) rather than the deprecated v1 shape (name/aliases/labels/acronyms/addresses).
• For vendor-supplied tools (DMP platforms, CRIS systems, repository platforms), ask the vendor directly for written confirmation of their v2 migration status rather than assuming it happened silently and correctly.
• Full field-level schema documentation is maintained by ROR at ror.readme.io/docs/schema-v2, and ROR’s technical support forum and [email protected] remain the right channel for migration questions specific to a given integration.

Why this happened now

ROR framed the v2 schema as a deliberate stability investment rather than an ongoing churn pattern — the goal was to fix structural problems inherited from GRID once, thoroughly, rather than making incremental breaking changes over time. The 18-month runway between v2’s April 2024 production launch and v1’s December 2025 shutdown, plus the intermediate step of defaulting unversioned traffic to v2 five months before the full cutover, gave integrators a graduated warning rather than a hard cliff. It is a reasonable template for how a small, community-governed identifier registry can version a schema without breaking downstream systems overnight — and it is worth institutions checking whether their own ROR-adjacent vendors handled the transition as cleanly as ROR itself managed the sunset.

Related CASRAI resources

• ROR ID — the core definition and how ROR IDs are structured and assigned.
• ROR IDs Explained: Why Research Organizations Need One and How to Get One
• How ROR, ISNI, Ringgold, and GRID Cross-Reference Each Other
• Identifier Crosswalk: Connecting DOI, ORCID, ROR, and Institutional IDs in Practice
• DMPTool’s ROR and Funder Registry Integration: What Auto-Fills in Your DMP
• ROR vs GRID — organisation identifiers compared