ORCID integration

Why ORCID matters for CRediT

ORCID issues persistent identifiers for researchers and operates a registry that publishers, funders, and institutions read from at every stage of the research lifecycle. When a CRediT-tagged work is deposited at Crossref or DataCite with the researcher's ORCID iD attached, the contributor roles propagate into the researcher's ORCID record. This is the closed-loop downstream use of CRediT and arguably the strongest single argument for its adoption.

The practical effect is that an early-career researcher can demonstrate to a hiring committee not just "I am an author on 17 papers" but "I was Investigation: lead on 12 of them and Software: lead on 5." That is a materially richer signal — one that hiring panels, tenure committees, and funders are beginning to read. ORCID's own guidance on contributor information for works is documented in the ORCID FAQ on contributor information.

Where the data enters ORCID

There are three practical paths. The first is the one most institutions and publishers should prefer.

Automatic, via Crossref or DataCite. When a deposit contains both an ORCID iD and CRediT roles, ORCID's auto-update systems can ingest the work and write the roles to the researcher's record on their behalf, subject to the researcher having granted permission to the relevant trusted organisation.
Direct, via the ORCID Public or Member API. A publisher with a Member API credential can write a work object containing structured contributor data directly to a researcher's record, using an OAuth token granted by the researcher.
Manual, via the ORCID UI. A researcher can add or edit a work on their own record and select CRediT roles per contributor. This is the fallback when no upstream automation is in place.

The works payload, in outline

ORCID's API accepts works in XML or JSON. The relevant block for CRediT lives inside contributors[].contributor-attributes. Each contributor declares a role from the CRediT vocabulary using the role's canonical URI as the value.

Truncated ORCID work payload with CRediT roles

json

{
  "title": {
    "title": { "value": "Example research paper" }
  },
  "type": "journal-article",
  "external-ids": {
    "external-id": [
      { "external-id-type": "doi",
        "external-id-value": "10.1234/example.5678",
        "external-id-relationship": "self" }
    ]
  },
  "contributors": {
    "contributor": [
      {
        "contributor-orcid": {
          "uri":  "https://orcid.org/0000-0001-2345-6789",
          "path": "0000-0001-2345-6789",
          "host": "orcid.org"
        },
        "credit-name": { "value": "Zhang San" },
        "contributor-attributes": {
          "contributor-sequence": "first",
          "contributor-role": "https://casrai.org/credit/roles/conceptualization"
        }
      }
    ]
  }
}

A single contributor may appear multiple times in contributors[] with differentcontributor-role values to represent multiple CRediT roles. The role identifier must be the canonical URI in the casrai.org/credit namespace; the legacy CASRAI-era identifiers are deprecated.

Posting a work to the Member API

Publishers and institutions with an ORCID Member API credential authenticate using OAuth 2.0, receive an access token scoped to the researcher's record, and POST the work to the /v3.0/{orcid}/work endpoint. The exchange is documented in the ORCID API documentation.

POST a work

bash

curl -sS -X POST "https://api.orcid.org/v3.0/0000-0001-2345-6789/work" \
  -H "Authorization: Bearer $ORCID_ACCESS_TOKEN" \
  -H "Content-Type: application/vnd.orcid+json" \
  --data @work.json

Recommended publisher workflow

Collect ORCID iDs and CRediT roles at submission. The Public Knowledge Project's OJS plugin and several commercial submission systems already support this.
Store the contributor data as structured rows, never as free text. The JATS XML encoding and the JSON-LD encoding both assume per-contributor, per-role rows.
Include both the ORCID iDs and the CRediT role URIs in the Crossref deposit or DataCite deposit.
Let ORCID's auto-update do the propagation. Avoid bespoke ORCID writes unless there is a workflow reason — duplicate work entries on a researcher's record are a common support burden.