CASRAI Dictionary

Tag: orcid api documentation

  • ORCID Registry vs Institutional Repository

    Researcher metadata should live in both systems, but for different reasons: the ORCID registry holds the person-owned identity record a researcher carries between institutions, while the institutional repository or CRIS holds the institution-owned record used for reporting, compliance, and assessment. The two should be kept aligned through automated API feeds, not parallel manual entry.

    The ORCID registry is a global, non-proprietary database of persistent digital identifiers — ORCID iDs — that let a researcher maintain one authoritative, portable record of their affiliations, works, and funding across every system they touch. That single design fact is what determines the division of labour with institutional systems, and it is the source of most of the “where does this data actually live” confusion research offices report.

    What is the ORCID registry, and what is it for?

    The ORCID registry launched in October 2012 as a non-profit, member-supported alternative to the proprietary author-ID systems then run by individual publishers and databases. Its governing principle, stated in ORCID’s own registry documentation, is that individuals own their record: researchers — not institutions or publishers — control what is displayed publicly, what is shared with “trusted organisations,” and who those organisations are.

    This person-centric design means the registry is built to follow a researcher across employers, disciplines, and countries. It is not built to answer institution-level questions such as “which outputs count toward our next research assessment” — that is a different data model entirely, owned by a different actor.

    What do institutional repositories and CRIS platforms manage instead?

    Institutional repositories and Current Research Information Systems (CRIS) — platforms such as Pure, Symplectic Elements, and DSpace-CRIS — exist to serve the institution’s reporting, compliance, and visibility needs, not the researcher’s portable identity. They aggregate outputs, grants, and staff affiliations at the organisational level, typically structured around the CERIF (Common European Research Information Format) data model maintained by euroCRIS.

    This is also where regulatory deadlines bite. Under the UK’s Research Excellence Framework open-access policy, outputs must be deposited in an institutional repository within three months of acceptance to remain eligible for the next assessment exercise — a requirement that will continue to apply under REF 2029. That obligation sits squarely with the institution, not with ORCID.

    Where should each type of researcher metadata actually live?

    In practice, the split is not “ORCID or CRIS” but “which record is authoritative for which fact.” The table below sets out the practical division of labour that most research offices converge on once duplicate entry becomes painful enough to fix.

    Metadata type Authoritative home Why
    Person identity, career history, cross-institution works list ORCID registry Researcher-owned, portable, survives institutional moves
    REF/assessment-eligible outputs, funder compliance records Institutional CRIS/repository Institution is legally accountable for reporting accuracy
    Grant and funder affiliation data Both, synchronised Funders (e.g. UKRI) require an ORCID iD at application, then institutions track spend internally
    Public-facing researcher profile ORCID registry (primary), CRIS-fed institutional page (secondary) One canonical identity, many display surfaces

    UKRI has required an ORCID iD from principal and co-investigators applying for funding across its research councils since 2023, which makes the registry the practical entry point for grant-related identity data even though the institution remains the system of record for compliance reporting.

    How do auto-update feeds eliminate duplicate data entry?

    Manual double-entry — typing the same publication into a CRIS and then again into an ORCID record — is the single biggest source of researcher frustration with metadata systems, and it is entirely avoidable. ORCID’s own registry documentation is explicit about the goal: reduce the burden on researchers and improve how information is shared, rather than asking them to re-key it.

    The mechanism is ORCID’s Member API, which — unlike the read-only Public API — allows an authenticated institutional system to write updates directly to a researcher’s record with their permission. A properly configured integration works in both directions:

    • CRIS-to-ORCID push: when a researcher deposits a new output in the institutional repository, the system automatically writes it to their ORCID record, tagged with the institution as the data source.
    • ORCID-to-CRIS pull: when a researcher joins an institution, the CRIS uses ORCID’s “search-and-link” workflow to pull their existing works and affiliation history into the local profile without re-typing.
    • Provenance tagging: every item on an ORCID record carries a visible source tag, so a reviewer can see whether an entry came from the researcher, an institution, a publisher, or a funder.

    Platforms such as DSpace-CRIS offer this bidirectional synchronisation as a built-in feature rather than a custom build, and ORCID’s “trusted organisation” permission model means the researcher grants and can revoke that write access at any time — the delegation is explicit, not implicit.

    Common questions about the ORCID registry

    What is an ORCID registry?

    An ORCID registry is the central, non-proprietary database that issues and stores ORCID iDs — persistent digital identifiers that disambiguate individual researchers and link them to their affiliations, works, and funding records. It is maintained by ORCID, a member-supported non-profit, and researchers register and control it directly rather than an institution or publisher owning the record.

    Can I look up someone’s ORCID?

    Yes. The public search function on the ORCID registry lets anyone look up a researcher’s public profile by name, affiliation, or ORCID iD, subject to whatever privacy settings that individual has chosen. Fields marked private by the record holder will not appear in public search results, even though the underlying record still exists.

    Who can register for ORCID?

    Anyone engaged in research, scholarship, or innovation can register for an ORCID iD directly and free of charge, regardless of career stage, discipline, institution, or country. This open registration model is what allows the identifier to persist across job changes, unlike institution-issued staff or repository IDs that expire when someone leaves.

    Does ORCID cost money?

    Registering for and using an ORCID iD is always free for individual researchers. Costs only arise for organisations: institutions, publishers, and funders that want Member API write access — the level needed for auto-update integrations with a CRIS or repository — pay ORCID membership dues, while read-only lookups via the Public API remain free.

    Implications for research offices and publishers

    For research administrators, the practical takeaway is not to choose between the ORCID registry and the CRIS but to stop treating them as separate data-entry destinations. Institutions that configure bidirectional API sync report far fewer profile-accuracy complaints from academic staff, because researchers enter a change once and it propagates outward.

    For publishers and funders, the same logic applies to contributor metadata: ORCID records can carry CRediT contributor-role tags alongside a work, so a journal’s manuscript system, the author’s ORCID record, and the institution’s CRIS can all reference the same role assignment rather than three independent descriptions of who did what.

    Outlook: toward a single source of truth

    The direction of travel across research information management is unambiguous: person-level identity consolidates in the ORCID registry, institution-level reporting consolidates in the CRIS, and the connective tissue between them is API-driven synchronisation rather than parallel manual records. As funders such as UKRI extend ORCID requirements further into the grant lifecycle, institutions that have not yet automated their CRIS-to-ORCID feeds will face growing duplicate-entry costs relative to those that have.

    Research offices evaluating a CRIS or repository upgrade should treat native, bidirectional ORCID Member API support as a baseline procurement requirement, not an optional add-on — the alternative is asking researchers to keep doing by hand what the API was built to automate.

  • ORCID Database: Inside the Public Data File

    The ORCID database’s annual public data file is a bulk, machine-readable snapshot of every public record in the ORCID registry, released once a year under a CC0 public-domain dedication. It is not the same thing as ORCID’s live summary statistics page — the data file is a static, downloadable dataset built for large-scale analysis of PID adoption, while the statistics page is a running counter of registrations. Together they answer different questions for anyone studying how persistent identifiers are being taken up across research.

    ORCID (Open Researcher and Contributor ID) is a non-profit registry that issues a free, unique 16-character identifier so that individual researchers and contributors can be distinguished from others with similar or identical names. The ORCID database that underpins this registry is what the annual public data file exports in bulk form — and that export is the subject of this analysis.

    What is the ORCID public data file?

    The ORCID public data file is a full export of every field that ORCID record-holders have marked as publicly visible, packaged as a single downloadable dataset rather than served record-by-record through the API. ORCID has released one of these files annually since 2013, hosting each release on the Figshare repository with a persistent DOI so that the exact version used in a study can always be cited.

    Access requires no ORCID membership and no API credentials. Anyone — a bibliometrician, a funder’s policy team, a university library, or an independent developer — can download the file directly. This “no gatekeeping” design is deliberate: ORCID’s registry exists to resolve author-name ambiguity across the whole scholarly ecosystem, and the organisation has treated bulk openness of public data as part of that public-interest mandate since the file’s first release.

    What does the annual dataset actually contain?

    Since the 2018 release, the public data file has been split into two components rather than one monolithic archive. This structural change reflects the growing size and complexity of individual records as ORCID’s activity metadata schema expanded.

    • Summaries file: one compact record per ORCID iD, covering biography, employment, education and other profile-level fields.
    • Activity files: separate, more granular files carrying the full public detail of works, funding, peer review and other activities linked to each iD.

    Both components are distributed as XML, the format ORCID’s underlying registry schema is built on; community-maintained conversion tools exist for teams that prefer JSON for downstream processing. Because works metadata in the schema can also carry contributor-role tags, the dataset increasingly includes role-level authorship detail as well as bare authorship claims — useful for anyone tracking how granular contribution reporting is spreading, distinct from simple co-authorship lists.

    As of August 2022, ORCID’s own statistics reported 14,727,479 live iDs and 1,258 member organisations, according to figures published on the ORCID Statistics page and reproduced in ORCID’s public reporting. Registration volumes of that scale are exactly what make the annual file a meaningful basis for adoption-trend research rather than a curiosity dataset.

    How does it differ from ORCID’s summary statistics?

    ORCID’s public-facing statistics page shows a live, aggregate count — total registrations, year-on-year growth, member numbers — updated continuously as the registry changes. The public data file is the opposite in every operational sense: a frozen, record-level snapshot taken at a fixed point in time, distributed once a year, and never updated after release.

    Attribute Public data file Summary statistics
    Granularity Every public field of every public record Aggregate totals only
    Update frequency Annual (fixed snapshot) Continuous / real time
    Format Bulk XML archive, downloaded once Web page / lightweight API counters
    Licence CC0 1.0 public domain dedication Published figures, not a dataset
    Typical user Researchers, funders, PID analysts General public, journalists, members

    This distinction matters for anyone citing ORCID in research administration literature: a claim about “how many researchers have ORCID iDs today” belongs to the statistics page, while a claim about “what fraction of ORCID works records carry funder identifiers” or “how affiliation self-reporting has changed by country” can only be answered from the bulk file itself.

    What can researchers do with the open dataset?

    Because the file is CC0-licensed and covers the full registry rather than a sample, it supports analysis no API query against individual records could replicate at scale. Typical uses include:

    • Measuring PID adoption trends by country, discipline or institution type over successive annual releases
    • Cross-linking ORCID iDs to DataCite and Crossref DOI metadata to study identifier coverage across the publication-funding-repository chain
    • Auditing how completely researchers populate employment and affiliation fields, which underpins institutional-attribution accuracy in research information systems
    • Building reproducible, citable PID-landscape studies, since each annual file carries its own Figshare DOI

    Since October 2015, DataCite and Crossref have used ORCID’s auto-update mechanism to write newly registered DOI metadata directly into linked ORCID records, which means the annual file increasingly reflects publication and dataset activity that researchers never manually entered themselves — a provenance detail that matters when interpreting completeness metrics from the dump.

    Answer-first Q&A

    What is the ORCID database?

    The ORCID database is the registry of unique 16-character identifiers, and associated public profile data, that ORCID Inc. maintains to distinguish individual researchers and contributors. It underlies both the live registry website and the annual public data file that exports the registry’s public content in bulk.

    Is ORCID iD public?

    An ORCID iD itself is always public once created, but the surrounding profile data is not automatically so. Record-holders set visibility settings field-by-field, and only fields marked public are exported into the annual data file or returned by the public API.

    Is ORCID free to use?

    Yes. Registering for and using an ORCID iD is free for individual researchers, and the public data file itself is free to download under a CC0 dedication. ORCID’s revenue instead comes from paid membership fees charged to institutions, publishers and funders that integrate with the registry.

    How do you find an ORCID iD?

    Individuals can search the ORCID registry directly by name at the public ORCID website, or look up a specific record via its 16-character identifier. Institutions and developers needing bulk lookups instead query the public API or work from the annual data file rather than searching one iD at a time.

    Implications for institutions and PID researchers

    For research administrators and institutional leaders, the annual public data file is the only reliable way to benchmark ORCID adoption across a whole sector rather than a single institution’s membership dashboard. Funders assessing whether a mandate for ORCID iDs has actually changed researcher behaviour need a full-registry snapshot, not a live counter that only reports totals.

    For developers and PID researchers, the file’s annual cadence and DOI-stamped releases mean every study can specify exactly which snapshot it used — a reproducibility property that live API queries, by their continuously-changing nature, cannot offer. As ORCID’s works metadata increasingly captures structured contributor-role information, future editions of the public data file are likely to become a primary source for studying how granular authorship attribution is spreading across disciplines, alongside identifier adoption itself.

  • How to Link ORCID to Publications: 2 Methods

    Linking a publication to ORCID means associating your 16-digit ORCID iD with a specific work record — either automatically through a Crossref or DataCite metadata feed authorised when you submit a manuscript, or manually by entering a DOI, PubMed ID, or BibTeX file into the Works section of your ORCID record. Auto-updated works carry a materially stronger trust signal than self-asserted entries, because the claim originates from a third-party registration agency rather than the researcher.

    ORCID is a non-proprietary, persistent digital identifier that distinguishes individual researchers from one another and links them to their publications, datasets, funding, and institutional affiliations. Understanding how to link ORCID to publications correctly — and which method to use for which purpose — determines whether that record reads as verified evidence or as an unaudited self-report.

    What Linking a Publication to ORCID Actually Means

    An ORCID “Work” is any research output — a journal article, dataset, preprint, conference paper, or software release — attached to a researcher’s ORCID record. Each record can hold up to 10,000 works, a ceiling ORCID imposes to protect Registry performance, according to ORCID’s own support documentation.

    Every work carries a source: the entity that added it. That source field is the whole point. A work added by the researcher themselves is labelled with the researcher’s own name as source. A work added via an authorised integration — a publisher, Crossref, DataCite, or a research information system — is labelled with that organisation’s name as source. This single metadata field is what separates a verified claim from a self-report.

    How Auto-Update Works via Crossref and DataCite

    Auto-update is a “push” mechanism, not something a researcher does manually after the fact. It runs on trust relationships a researcher grants once and that then apply to every future publication. Publishers who register content with Crossref (for journal articles) or DataCite (for datasets and other outputs) can include an author’s ORCID iD in the deposited metadata.

    • Set-up: the researcher supplies their ORCID iD during manuscript or dataset submission and authorises the publisher as a “trusted organisation” on their ORCID record.
    • Trigger: when the work is registered and its DOI is minted, Crossref or DataCite passes the metadata, including the ORCID iD, back to the ORCID Registry.
    • Result: the work appears on the researcher’s ORCID record automatically, with the publisher or registration agency listed as the source — no manual entry required, then or ever again.

    ORCID’s own guidance favours this route: “Allowing trusted organizations to add information to your record ensures the data connected with your ORCID iD is authoritative and trustworthy,” per ORCID Support’s “Add works to your ORCID record” article. Auto-updated entries are visually flagged in the ORCID interface with a distinct icon next to the work.

    How Manual Import Works via DOI, PubMed ID, and BibTeX

    Manual import is a “pull” process the researcher initiates, typically to backfill a body of existing work that predates any auto-update authorisation. ORCID Support lists four routes, in addition to auto-update, from the Works section’s +Add menu:

    1. Import from other services — searching connected databases such as Web of Science, Scopus, or Crossref Metadata Search and bulk-importing matched records.
    2. Add work with a DOI — pasting a Digital Object Identifier, which pulls the full citation from the DOI registration agency.
    3. Add work with a PubMed ID — the same principle, using PMID for biomedical literature indexed in PubMed.
    4. Import a BibTeX file — exporting a library from Google Scholar, EndNote, or Mendeley to a .bib file and uploading it directly.
    5. Add work manually — typing citation details by hand for works with no identifier at all.

    Each route is initiated by the researcher and populates the record once, rather than on an ongoing basis. Identifier-based and BibTeX import draw on structured external metadata, so they are more reliable than fully manual entry, but the source field still reads as the researcher, not a registration agency, unless the import tool explicitly attributes the deposit.

    Auto-Update vs Manual Import: Which Carries More Trust?

    Both routes populate the same Works section, but they are not equivalent as provenance signals. The distinction that matters to institutions, funders, and research-integrity reviewers is who is asserting the claim, not how the citation data was formatted.

    Factor Auto-Update (Crossref/DataCite) Manual Import (DOI/BibTeX/Manual)
    Who initiates it Publisher, at registration/DOI-minting time Researcher, whenever they choose
    Recorded source Publisher or registration agency The researcher themselves
    Coverage Future works only, from authorisation onward Past and present works, added retrospectively
    Ongoing effort None after initial authorisation Repeated per work or per batch
    Trust signal Third-party verified Self-asserted

    An auto-updated work is corroborated by an external registration agency’s records — the kind of independently verifiable evidence that research assessment exercises and grant compliance checks look for. A manually entered work, even one anchored to a real DOI, still relies on the researcher’s own account linking “this person” to “this ORCID iD.” Institutions running authorship audits should treat the two categories differently, not as interchangeable Works-tab entries.

    The practical recommendation, and the one ORCID itself gives, is to use both: manual import to backfill the existing publication history, and auto-update authorisation with every future submission so new works never need re-entering.

    Frequently Asked Questions

    Can I use my ORCID iD for publications?

    Yes. An ORCID iD can be attached to any publication at submission, and most scholarly publishers now capture it as standard metadata. Once attached, that iD becomes the persistent link between the researcher and the work, regardless of name changes, institutional moves, or common-name ambiguity.

    How do I add an ORCID iD to a manuscript?

    Most journal submission systems prompt for an ORCID iD during author registration, then authenticate it via ORCID’s own sign-in flow. Once authorised, the publisher can include that iD in the metadata deposited with Crossref or DataCite when the article or dataset is registered and assigned a DOI.

    How do I link ORCID to a publisher such as Elsevier?

    Publisher platforms, including Elsevier’s Editorial Manager, typically show a “Use my ORCID” or “Connect ORCID” button during login or registration. Clicking it opens an ORCID authentication window; after signing in and authorising access, the publisher can read and, where permitted, write publication data to the record.

    What This Means for Institutions, Publishers, and Funders

    For research administrators, the auto-update versus manual-import distinction is not a technical footnote — it is a compliance and evidence question. UKRI’s Funding Service requires named investigators to supply an ORCID iD as part of grant applications, and institutions increasingly rely on ORCID’s Works data to populate REF-style outputs lists and funder reports. Data drawn from auto-updated, publisher-sourced Works entries is defensible evidence in that context; data drawn from unaudited manual entries is not, without further checking.

    This “who asserts the claim” logic underpins contributor-level attribution more broadly. CASRAI originated the CRediT contributor role taxonomy in 2014, and the standard is now stewarded by NISO as ANSI/NISO Z39.104-2022. CRediT statements and ORCID auto-updates share one design principle: attribution is more trustworthy when a party other than the researcher is on record as having made the claim. Institutions building publication-verification workflows, for CRediT contributor statements or ORCID Works alike, should apply the same provenance test.

    Publishers that deposit ORCID iDs with Crossref or DataCite at DOI registration are, in effect, running the infrastructure that makes auto-update possible at scale. Where that deposit step is skipped, researchers are pushed back onto manual import by default, regardless of preference.

    Conclusion: Building a Verifiable Publication Record

    Getting works onto an ORCID record is straightforward mechanically: import from a connected database, enter a DOI or PMID, upload a BibTeX file, or authorise auto-update at submission. The strategic choice is which of these to rely on for which purpose. Manual import is the right tool for backfilling a career’s worth of existing publications in one pass. Auto-update via Crossref and DataCite is the right tool for every submission from today onward, because it produces a record institutions, funders, and integrity reviewers can treat as third-party verified rather than self-reported. As research assessment increasingly leans on machine-readable provenance rather than researcher-supplied CVs, that distinction is likely to matter more, not less.

  • ORCID Sandbox: A Developer’s Guide to Testing

    The ORCID sandbox is a free, fully functional copy of the ORCID Registry — at sandbox.orcid.org — that lets developers register test accounts, request API credentials, and run real Public and Member API calls against dummy data before touching production. No ORCID membership is required to test the Member API in the sandbox, and nothing you do there can affect a real researcher’s ORCID record.

    ORCID is a non-profit registry that assigns researchers a free, persistent 16-digit identifier (an ORCID iD) and connects it to their affiliations, works, and funding through a public API and a membership-tier Member API. Building an integration means testing the OAuth handshake and both API tiers in the sandbox before requesting production credentials.

    What is the ORCID sandbox and how does it differ from production?

    The sandbox is a mirror of the production ORCID Registry running on isolated test infrastructure. It behaves the same way as the live registry, with a handful of deliberate exceptions built in for safety.

    • Sandbox accounts only send verification and notification emails to @mailinator.com addresses, so registration mail never leaks to real inboxes.
    • Sandbox data is not backed up and can be wiped without notice — never store anything you need to keep there.
    • Anyone can request sandbox Member API credentials, even without an ORCID membership; production Member API access requires a paid membership tier.
    • Base URLs differ from production, which is the detail most tutorials skip:
    Component Sandbox Production
    Registry / sign-in sandbox.orcid.org orcid.org
    Public API base (v3.0) pub.sandbox.orcid.org/v3.0 pub.orcid.org/v3.0
    Member API base (v3.0) api.sandbox.orcid.org/v3.0 api.orcid.org/v3.0
    OAuth authorize endpoint sandbox.orcid.org/oauth/authorize orcid.org/oauth/authorize
    OAuth token endpoint sandbox.orcid.org/oauth/token orcid.org/oauth/token

    Under ORCID’s published integration guide, every client credential, redirect URI, and access token issued in the sandbox is scoped to sandbox hostnames only — a sandbox client ID will not authenticate against production, and vice versa. This is the single most common cause of “invalid client” errors when developers copy sandbox code straight into a production deployment.

    Public API vs Member API: which scope does your integration need?

    ORCID publishes two distinct APIs, and choosing the wrong one wastes weeks of sandbox testing. The Public API is free for non-commercial use and gives read-only access to publicly visible record data — no ORCID membership required. The Member API requires production membership (though not in the sandbox) and adds write access plus read access to “trusted” limited-access data that a researcher has authorised your organisation to see.

    Capability Public API Member API
    Read public record data Yes Yes
    Read trusted/limited-access data No Yes, with researcher permission
    Write or update a record No Yes, with researcher permission
    Membership required in production No Yes
    Membership required in sandbox No No — open to anyone testing
    Typical use case “Sign in with ORCID”, search, display Populate affiliations, works, funding on a record

    Research information systems, manuscript submission platforms, and repository software (for example, systems built on OJS) most often need Member API scopes because they write affiliation or works data back to a researcher’s record. Discovery tools and simple “sign in with ORCID” buttons typically only need the Public API.

    How do you register a sandbox client and complete the OAuth handshake?

    Every ORCID integration authenticates through OAuth 2.0, and the sandbox forces you to exercise the full handshake before production ever sees a request. The sequence is the same for Public and Member API integrations, only the scopes and base URLs change.

    1. Create a sandbox account. Register at sandbox.orcid.org/register using a made-up @mailinator.com address so you can retrieve the verification email from the public Mailinator inbox.
    2. Register a client application. From the account’s Developer Tools section (or via ORCID’s sandbox Member API request form), obtain a client ID and client secret plus a registered redirect URI.
    3. Send the user to the authorize endpoint. Redirect to the sandbox authorize URL with response_type=code, your client_id, the requested scope, and your redirect_uri.
    4. Capture the authorization code. After the researcher grants permission, ORCID redirects back to your registered URI with a short-lived authorization code.
    5. Exchange the code for a token. POST the code, client ID, and client secret to the sandbox token endpoint to receive an access token bound to that researcher’s ORCID iD.
    6. Call the API. Use the access token as a Bearer credential against the sandbox Public or Member API base URL to read or write record data.

    Because sandbox credentials only work against sandbox hostnames, this whole sequence must be repeated — with new, separately issued production client credentials — once testing is complete. ORCID’s own guidance recommends reviewing its integration checklist, and for Member API integrations, demonstrating the working sandbox flow to the ORCID team, before requesting production access.

    What goes wrong when moving from sandbox to production?

    Most production failures trace back to configuration, not code. Watch for these before cutover:

    • Hard-coded sandbox hostnames. Any string reference to sandbox.orcid.org, pub.sandbox.orcid.org, or api.sandbox.orcid.org left in production config will silently fail authentication.
    • Redirect URI mismatch. The redirect URI used in the OAuth request must exactly match the one registered against that specific client ID — sandbox or production, they are registered separately.
    • Wrong API tier requested. Applying for Member API production access without an active ORCID membership will be rejected; Public API access has no such requirement.
    • Assuming sandbox reliability. ORCID explicitly states the sandbox carries no uptime or data-retention guarantee, so integration tests should not depend on long-lived sandbox test records.

    Institutions building or commissioning a research administration system that writes to ORCID records — a current research information system (CRIS), grants platform, or repository — should budget sandbox testing time separately from production onboarding, since ORCID’s own review step for Member API access is a manual, asynchronous process.

    Sandbox and API questions, answered

    Does ORCID have an API?

    Yes. ORCID offers a Public API for reading publicly visible record data and connecting systems without ORCID membership, and a Member API for member organisations to read trusted data and write affiliations, works, or funding to a record with the researcher’s permission.

    Is ORCID API free?

    The Public API is free for non-commercial use by individuals and organisations under ORCID’s Public API terms of service. The Member API, in production, requires a paid ORCID membership tier — though sandbox Member API testing credentials are free and open to anyone, member or not.

    What is ORCID public API vs member API?

    The Public API allows anyone to read public-access information on ORCID records via machine-to-machine calls. The Member API is restricted to member organisations and additionally supports reading limited-access “trusted” data and writing or updating a researcher’s record with authorisation.

    The ORCID sandbox exists precisely because both API tiers, and the OAuth handshake connecting them, need to be exercised end-to-end — with real credentials and real error responses — before a single production request is made. Treat it as a mandatory rehearsal step, not an optional convenience: budget time for the manual Member API review, hard-code nothing that points at a sandbox hostname, and re-issue every credential fresh for production.