ORCID’s Integration and Data Roadmap (IDR) work, which culminated in late 2025 with the 4.0 release of the public and member APIs, is the most consequential PID infrastructure change of the year for anyone who cares about the contributor-affiliation-funding crosswalk. The headline is technical: a new contributions resource that supersedes the old works and employment pairing for representing what a researcher did, where, on whose money, and with whom. The implications reach into nearly every persistent-identifier integration CASRAI tracks.
What 4.0 actually changes
The pre-4.0 ORCID record was a federation of resource types: works (with DOIs), employment (with ROR organisation IDs), education, funding (with grant IDs and Funder Registry entries), peer reviews, and the like. Each was useful in isolation. None of them carried the relations between them in a structured form. If a researcher’s ORCID record listed a paper, an employment at the institution that hosted the work, and a grant that funded the work, those three facts sat in separate resources with no machine-readable link.
4.0 introduces a top-level contribution entity that binds these. A contribution carries: a primary artefact (DOI, software identifier, dataset identifier, or RAiD), a set of CRediT roles with the degree-of-contribution qualifier, an affiliation in force at the time of the contribution (with ROR), funding in force at the time (with Funder Registry or ROR for the funder, plus the grant identifier and ideally a RAiD), and a temporal span. The relationships are explicit and queryable. A consuming system can ask: what did this researcher contribute, at this affiliation, under this grant, on this date? — and get an answer without inference.
The CRediT-at-record-level integration matures
The 2024 work to allow CRediT roles to live on an ORCID record (not just in publisher JATS) was the precursor to 4.0. The integration shipped, was widely adopted, and exposed two limitations that 4.0 closes. First, role assignments lived inside the work resource, making it awkward to express a Conceptualization role spanning several papers and datasets. Second, the qualifier was carried only at per-work granularity. 4.0 lets a CRediT role attach to a contribution that groups multiple artefacts, with the qualifier traveling with the contribution.
Practical example: a researcher who is Lead for Conceptualization across a clinical trial’s primary paper, protocol paper, registered data, and statistical analysis plan should be representable that way. Pre-4.0, the assertion had to be repeated four times; post-4.0, it lives on the contribution entity. See the ORCID implementation guide for the API patterns.
RAiD becomes a first-class citizen
One of the unsung wins in 4.0 is the elevation of RAiD to a first-class identifier alongside DOI. Pre-4.0, RAiD could be carried in an ORCID funding resource as an external identifier, but the schema treated it as a second-tier metadata field. 4.0 adds RAiD to the primary identifier set for both contributions and funding, with the same validation and resolution support as DOI.
This matters because RAiD is increasingly the canonical project-level identifier, and ORCID is increasingly the canonical person-level record. The interlock — researcher X contributed to project RAiD Y, which produced papers A, B, C — is now a structured query rather than a string-match exercise.
Affiliation history with PIDs at both ends
The 4.0 employment and affiliation model has been quietly tightened. Every affiliation now requires a ROR organisational ID at registration; legacy string-only affiliations are preserved but flagged. The optional department field accepts a ROR sub-organisation ID where one exists (the ROR hierarchy work has caught up to make this practical), or a free-text department name as a fallback. The result is that affiliation history on an ORCID record is now reliably machine-readable at the ROR ID level.
For institutions running a CRIS, this closes a longstanding crosswalk gap. CRIS-to-ORCID deposit can now write structured affiliations that ORCID-to-CRIS retrieval can read back without ambiguity. The CASRAI CRIS integration guide has been updated with the 4.0 deposit patterns.
What CASRAI integrations need to do
Three things, in priority order.
- Update CRediT JATS round-trips. Publishers depositing structured CRediT to ORCID via the member API should switch to the
contributionresource for new deposits. Legacy works-with-roles deposits will continue to be accepted through 2026 but will be migrated server-side in 2027. The CASRAI CRediT JATS integration patterns now include both the legacy and the 4.0 deposit forms; new integrators should implement only the 4.0 form. - Validate ROR IDs at affiliation deposit. A CRIS or publisher pushing affiliation data to ORCID should resolve and validate the ROR ID before deposit. The 4.0 API will reject obviously bad ROR IDs at the schema layer but will accept ROR IDs that resolve to deprecated or merged records. A pre-deposit validation pass against the ROR public API catches the common error cases.
- Test the funding-to-contribution link. If your integration writes funding entries, link them explicitly to the contributions they funded via the new
funded_byrelation on the contribution resource. This is the integration point that was missing pre-4.0 and that downstream consumers (funder dashboards, institutional reporting) most want to query.
Backwards compatibility and the migration window
ORCID’s commitment is that the 3.x APIs remain available through end-of-2027, with the 4.0 API the recommended target from now. The data model migration is largely automatic for existing records: pre-existing works with associated employment and funding are projected into the contribution model server-side. Consumers reading via the 4.0 API will see contribution entities even for data that was deposited in the 3.x form.
The one wrinkle is CRediT role assignments that were deposited in 3.x without explicit qualifiers. These project into the contribution model with no qualifier set — a valid state, but less informative than it could be. Publishers should re-deposit historical CRediT data with qualifiers where they have them during 2026.
What this enables downstream
The most interesting consequence of 4.0 is the ability to ask compound questions across the PID graph. Which researchers, affiliated with which institutions, contributed in which CRediT roles, to outputs funded by which funders, on which projects? — that query reduces to a structured traversal across ORCID, ROR, Crossref/DataCite, and the Funder Registry, with RAiD optionally tying the project layer together. The OpenAIRE Graph already operationalises a version of this; 4.0 makes it cleaner.
For institutions, the practical implication is that reporting against funder mandates becomes substantially less manual. For publishers, the JATS-to-ORCID deposit becomes more valuable because it now persists in a queryable graph. For funders, the funder-PID-to-output traceability that ORCID has long promised starts to deliver at scale.
What’s still missing
4.0 does not solve everything. The contributor-affiliation-funding triple is now structured; the contributor-contributor relationship (collaboration graphs, mentorship) is not. A relationships resource is in development but not in 4.0. CARE-aligned identifiers for Indigenous researchers are also still in design.
CASRAI’s integration tracking will follow 4.0 through 2026. The persistent-identifiers domain is being updated to reflect the contribution model; the ORCID federation page tracks member implementation.
Leave a Reply