CASRAI Dictionary

Tag: orcid sandbox

  • 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.

  • ArXiv ORCID Authentication for Preprints

    ArXiv ORCID authentication lets a researcher link a persistent ORCID iD to their arXiv account, and it is one of two models preprint servers use to establish who an author is before a paper ever reaches peer review — the other being direct “log in with ORCID,” used by bioRxiv. Neither model performs formal identity verification in the legal sense; both rely on ORCID’s OAuth authentication to confirm that the person submitting genuinely controls the ORCID iD they claim.

    ORCID authentication is the OAuth-based process by which a researcher proves control of their ORCID iD to a third-party system — such as a preprint server — by signing in directly at orcid.org, without ever sharing a password with that third party. This distinction matters for research administrators and developers assessing how much identity assurance a preprint record actually carries.

    How does ORCID authentication work before publication?

    ORCID authentication runs on a three-legged OAuth flow, documented by ORCID’s own integration guide. A system such as a preprint server creates a “Connect your ORCID iD” link; when a researcher clicks it, they are redirected to orcid.org, sign in with their own ORCID credentials, and explicitly grant the requesting system permission to read (and, for member integrations, write) specific parts of their record.

    ORCID then returns an authorisation code, which the preprint server exchanges for an access token. That token — not a copied-and-pasted ID number — is what proves the connection is genuine. According to ORCID’s documentation, the organisation does not permit manual entry of ORCID iDs in any workflow where authenticated collection is technically possible, precisely because typed-in IDs cannot prove ownership.

    • Public API: free, available to non-commercial and commercial integrations, sufficient for basic authenticated sign-in and read access.
    • Member API: requires ORCID membership, needed to write data (such as adding the preprint itself) directly to a researcher’s record.
    • Sandbox environment: a full ORCID Sandbox testing server lets integrators build and demo the OAuth flow before ORCID’s engagement team approves production Member API credentials.

    How arXiv verifies author identity with ORCID

    arXiv treats ORCID primarily as a disambiguation and record-linking layer rather than a submission gate. Authors link an existing ORCID iD — or create one during the process — via arXiv’s account dashboard, and the platform then prefers the ORCID iD over its own internal arXiv author identifiers wherever possible “in order to facilitate better data exchange,” per arXiv’s own documentation.

    Identity assurance on arXiv sits mainly in a separate, adjacent mechanism: endorsement. As of 21 January 2026, arXiv no longer accepts an institutional email address alone as sufficient qualification for a new submitter. Under the updated policy, a new author must now satisfy one of two paths:

    1. An institutional academic/research email address and prior authorship on a paper already accepted into the relevant arXiv endorsement domain, or
    2. Direct personal endorsement from an established arXiv author already active in that same domain.

    arXiv’s own guidance notes that authors contacting a potential endorser may include a link to their ORCID profile as supporting evidence, though ORCID linkage itself is not a mandatory endorsement criterion. Misrepresenting identity or institutional affiliation is, separately, a violation of arXiv’s code of conduct and grounds for account suspension.

    How bioRxiv verifies author identity with ORCID

    bioRxiv, operated by the non-profit openRxiv, takes a more direct authentication route. The platform offers a “Log in with ORCiD” option at the account level: when a submitter authenticates this way, bioRxiv receives an ORCID-verified identifier straight from ORCID’s OAuth flow, rather than a self-typed value.

    During manuscript submission, corresponding authors can also attach ORCID iDs for themselves and co-authors, which are then carried into the preprint’s metadata. This matters for provenance: under ORCID’s documented preprint workflow, an ORCID-member preprint server can add the work to an author’s ORCID record with a “Self” relationship, and later — once a peer-reviewed version exists — a publisher can add the journal article with a “Version of” relationship linking the two, grouping the preprint and its published descendant on one authoritative record.

    arXiv vs bioRxiv: ORCID identity assurance compared

    The two platforms diverge on where, and how strongly, ORCID authentication sits in the submission path:

    Feature arXiv bioRxiv
    ORCID collection point Account linking, post-registration Optional login and/or manuscript submission
    Authentication method Account-page OAuth link to ORCID Direct “Log in with ORCiD” OAuth sign-in
    Mandatory for submission? No — recommended, not required No — optional for authors and co-authors
    Separate identity gate Endorsement policy (updated 21 Jan 2026) Basic screening for offensive/non-scientific content
    Co-author ORCID capture Not built into the submission form Can be added at submission by corresponding author

    What this means for identity assurance ahead of peer review

    ORCID authentication and identity verification are not the same thing, and conflating them overstates what a preprint record actually proves. An authenticated ORCID iD confirms that a specific, persistent researcher account is behind a submission. It does not confirm a person’s legal name, employer, or credentials — those rest on the separate affiliation and endorsement checks each platform runs independently.

    Funders are pushing this authentication layer further upstream. UK Research and Innovation (UKRI) is building mandatory ORCID iD linking into its Funding Service for project leads, co-leads and fellows, with the requirement expected to take effect roughly six months after the relevant functionality launches, targeted for 2027. That shifts identity assurance earlier — to the funding-application stage — rather than leaving it solely to the preprint or journal submission step.

    For institutions and developers building on this infrastructure, the practical takeaway is definitive: treat an authenticated ORCID iD as strong evidence of account control, and treat endorsement, institutional email, and funder-linked ORCID mandates as the separate, complementary layers that build fuller identity assurance around it.

    Frequently asked questions

    Do arXiv papers appear on ORCID?

    Yes. Once an author links their ORCID iD to their arXiv account, arXiv’s works are unambiguously connected to that researcher’s broader scholarly record, helping distinguish them from authors with similar names across other platforms and repositories.

    How do I add an arXiv preprint to ORCID?

    Authors can search by arXiv identifier directly within their ORCID record’s “Add works” tool, or link their arXiv account to ORCID so eligible works sync automatically. Manual entry of someone else’s ORCID iD is not permitted under ORCID’s collection policy.

    Does an arXiv preprint count as a publication?

    Not in the traditional peer-reviewed sense. ArXiv preprints are not peer-reviewed before posting, so most journals and funders treat them as a distinct output type — citable, but separate from the peer-reviewed version of record that may follow.

    What is the arXiv identifier?

    The arXiv identifier (or arXiv ID) is a unique code assigned to every submitted paper, used to cite and retrieve it. It is distinct from an author’s ORCID iD, which identifies the person rather than the paper.

    Looking ahead

    arXiv and bioRxiv show two workable but distinct approaches to the same problem: using ORCID’s authenticated, OAuth-based identifiers to anchor preprint authorship without claiming to verify legal identity outright. As funders such as UKRI extend ORCID requirements into the funding-application stage, the identity-assurance chain around research outputs is likely to start earlier and grow more consistent — well before a manuscript ever reaches a preprint server or a peer-review desk.

    For research administrators mapping authorship and contribution practices onto institutional systems, understanding exactly what an authenticated ORCID iD does and does not prove is a prerequisite for sound research administration policy — not an afterthought.