CASRAI Dictionary

Author: MCP Service

  • ORCID Inc: Governance, Funding and Structure Behind the Registry

    ORCID Inc is an independent, US-incorporated non-profit that operates the ORCID registry, the free persistent identifier used by researchers worldwide. It is not owned by any publisher, university, or government body; it is governed by a Board of Directors elected from its dues-paying member organisations and funded almost entirely by orcid membership fees. For institutions deciding which identifier registries to build workflows around, that governance-and-funding structure is the real due-diligence question — more relevant than the technology itself.

    ORCID (Open Researcher and Contributor ID) is the identifier; ORCID Inc is the legal, non-profit organisation that builds, operates, and governs it. The two are often conflated, but the distinction matters for anyone assessing the registry’s long-term stability.

    What is ORCID Inc?

    ORCID Inc was incorporated as an independent, not-for-profit corporation in Delaware in August 2010, following a 2009 collaborative effort among publishers to resolve the “author name ambiguity” problem in scholarly communication. Its registry services launched on 16 October 2012, issuing the first ORCID iDs.

    The organisation’s own founding principles state that ORCID exists to support “a permanent, clear, and unambiguous record of research and scholarly communication,” that participation is open to any organisation with an interest in research, and that researchers will always be able to create, edit, and maintain their ORCID iD free of charge. Those principles — not a shareholder charter — are what ORCID Inc is legally bound to.

    Who governs ORCID? Board and membership structure

    ORCID Inc is governed by a Board of Directors elected by and from its member organisations — universities, publishers, funders, and professional societies. A founding governance rule requires that the majority of board seats be held by representatives of non-profit organisations, and the board reserves a seat for a non-member researcher, so commercial members cannot outvote the academic community they serve.

    Day-to-day leadership sits with an Executive Director, a role held by Chris Shillum since September 2020, who succeeded founding Executive Director Laurel Haak, appointed in April 2012. The Board itself has been chaired since 2016 by Véronique Kiermer of PLOS, following the organisation’s first chair, Ed Pentz of Crossref.

    • Board summaries and annual financial reports are published, a transparency commitment written into ORCID’s founding principles.
    • All ORCID software is released under an Open Source Initiative-approved licence.
    • Researcher-contributed data is available for bulk download under a CC0 waiver, subject to individual privacy settings.

    How is ORCID funded? The membership model

    ORCID Inc is sustained by orcid membership fees paid by organisations — not by researchers, who register and use their ORCID iD free of charge. Organisational members include research institutions such as Caltech and Cornell, major publishers including Elsevier, Springer, and Wiley, and funders such as the Wellcome Trust, which mandates ORCID iDs for grant applicants. By 2022, ORCID’s published statistics disclosure reported 1,258 member organisations and 14,727,479 live registry accounts, and ORCID states it has been fully self-sustaining on membership revenue since 2019, without reliance on the founding-era grant funding that underwrote its 2010–2012 build phase.

    This fee-for-institutions, free-for-researchers model is a deliberate design choice under ORCID’s founding principles, which require that any fees be set “to ensure the sustainability of ORCID as a not-for-profit, charitable organization” — not to generate surplus for distribution.

    ORCID Inc compared with other research-infrastructure non-profits

    ORCID Inc sits within a small cluster of membership-funded, non-profit organisations that maintain persistent identifiers for scholarly research. Comparing their governance and funding models helps explain why institutions increasingly treat “who runs it” as a trust signal in its own right.

    Organisation Identifier Founded Governance Funding model
    ORCID Inc ORCID iD (person) 2010 Board elected by members; majority non-profit Membership fees
    Crossref DOI (scholarly work) 2000 Membership association; publisher-elected board Membership + DOI registration fees
    DataCite DOI (research data) 2009 Consortium; General Assembly and Board Membership fees
    ROR ROR ID (institution) 2019 Community-governed by founding partners Grant-seeded, moving to community funding

    The pattern across all four is the same: none is a commercial entity, and each ties governance seats to its member community rather than to investors. ORCID’s identifiers are also formally interoperable with the International Standard Name Identifier (ISNI) under ISO 27729, with a reserved identifier block shared between the two systems — one of several technical cross-checks that reduce single-registry dependency risk for institutions.

    Answer-first Q&A: common questions about ORCID Inc

    What is ORCID Inc?

    ORCID Inc is an independent, US-incorporated non-profit organisation that operates the ORCID registry, a free, persistent digital identifier for researchers. Incorporated in Delaware in August 2010, it is not owned by any publisher, university, or government; it is sustained by fees paid by its dues-paying member organisations.

    Is ORCID a company?

    No. ORCID Inc is legally structured as a not-for-profit corporation, not a commercial company. It generates no shareholder profit, and any surplus is reinvested in the registry. Its founding rules require a board majority from non-profit member organisations, a safeguard against commercial capture of the infrastructure.

    Is ORCID legitimate?

    Yes. ORCID is used by over a thousand member organisations, including major publishers, funders such as the Wellcome Trust, and national research agencies in Italy and Australia. Its governance minutes, board composition, and financial reports are published openly, a transparency commitment embedded directly in its founding principles.

    Is ORCID like LinkedIn?

    No. LinkedIn is a commercial, advertising-funded social network; ORCID is a non-profit identifier registry with no social-networking or advertising model. ORCID’s role is narrowly technical — disambiguating researcher identity and linking it to verified contributions — governed by its membership, not by private commercial interests.

    What this means for institutions choosing which registries to trust

    For research administrators and institutional leaders, ORCID Inc’s structure is a useful template for evaluating any piece of shared research infrastructure: check who sits on the board, how funding flows, and whether commercial members can outvote the academic community. ORCID’s rule requiring a non-profit board majority, its published financials, and its CC0 data commitment together reduce the risk of the registry being redirected toward a single stakeholder’s commercial interest.

    The same governance-first lens applies to attribution standards more broadly. CASRAI originated the CRediT contributor role taxonomy in 2014; the standard is now stewarded by NISO as ANSI/NISO Z39.104-2022 — a comparable “originator hands off to a standards body” pattern that, like ORCID’s membership model, is designed to outlast any single founding organisation. Institutions building authorship and contribution-tracking workflows around ORCID iDs and CRediT roles are, in effect, betting on the durability of exactly this kind of community governance.

    Looking ahead, ORCID’s own strategic plan, ORCID 2030: Advancing the Future of Research, sets out a 2026–2029 focus on expanding the registry into a broader verifiable identity and contribution data hub. Whether that expansion strengthens or dilutes the non-profit, membership-governed model that has sustained ORCID since 2019 is the question institutional stakeholders — as both funders and voting members — are best placed to keep watching.

  • ORCID Search by Name: The Common-Name Problem

    ORCID search by name is the practice of looking up a researcher’s ORCID iD by typing their given and family name into the ORCID Registry search bar. It works well for uncommon names but breaks down at scale: shared names, name changes, and transliteration variants routinely return the wrong person, or hundreds of candidates with no way to tell them apart. ORCID exists precisely to remove this ambiguity — by attaching a persistent, person-controlled identifier to the researcher rather than relying on downstream systems to guess who “J. Smith” really is.

    ORCID is a non-proprietary, persistent digital identifier that research organisations, publishers, funders, and institutions use to distinguish one researcher from every other researcher with a similar or identical name. Once assigned, the identifier — a 16-character iD in the format 0000-000X-XXXX-XXXX — stays with that individual for their entire career, independent of name changes, institutional moves, or script transliteration.

    Why does searching by name fail at scale?

    Name-based author search fails because a personal name is not a unique key. It is a label that many people share, that changes over a career, and that renders inconsistently across writing systems. These are structural problems, not edge cases, and they compound as a database grows.

    • Common names. A search for a name shared by hundreds of active researchers returns a long, unranked list with no reliable way to isolate the right individual from the name alone.
    • Name changes. Marriage, divorce, gender transition, or a simple preference shift can mean a researcher publishes under two or more surnames across a career, splitting their record in half.
    • Transliteration variants. Names originating in non-Latin scripts — Chinese, Korean, Arabic, Cyrillic — are romanised inconsistently by different publishers and databases, so the same person can appear as several distinct “names” in search indexes.
    • Initials and abbreviation. Journal house styles that truncate given names to initials (“J. Smith” instead of “Jane Smith”) strip exactly the information a disambiguation algorithm needs most.

    ORCID’s own technical guidance is explicit that name search should not be treated as a substitute for identity verification. As ORCID’s public API documentation states: “We generally discourage organizations from adding ORCID iDs to their systems based on a search for researchers by name – it is far better to collect authenticated iDs.” That is a direct acknowledgement, from the registry operator itself, that name matching is a fallback, not a solution.

    How does ORCID solve disambiguation at the source?

    ORCID solves disambiguation by moving the identifier upstream, to the point where the researcher first registers, rather than leaving it to downstream systems to reconcile names after the fact. The researcher — not a matching algorithm — asserts who they are once, and every subsequent system references that single, stable identifier.

    This is a deliberate architectural choice. Traditional author-search tools (library catalogues, citation indexes, manuscript systems) built name-matching heuristics on top of bibliographic metadata that was never designed to carry identity information. ORCID instead treats identity as the primary object: the person registers directly, controls their own visibility settings, and authorises connections between their iD and their outputs via OAuth, rather than having a third party infer the link statistically.

    • Person-centric registration. The individual creates and owns the iD, so name variants, past affiliations, and preferred name forms live inside one authoritative record instead of being scattered across index entries.
    • Authenticated connections. Publishers, funders, and institutions collect the iD through an authenticated sign-in flow, confirming it belongs to the person submitting the work, rather than guessing from a name string.
    • Persistent visibility. The iD number itself is always publicly resolvable, even though the researcher can restrict visibility of the surrounding biographical detail — separating the stable identifier from the changeable metadata around it.

    Because the identifier does not change when a name does, transliteration and name-change problems that defeat string matching become non-issues: the iD, not the name string, is what every downstream system keys against.

    ORCID name search vs iD lookup: a comparison

    The table below sets out where a plain name search still has a role, and where it structurally cannot substitute for identifier-based lookup.

    Method Best used for Where it breaks down
    ORCID search by name A quick, informal check for an unusual name, or a first pass before narrowing with an institution filter Common names, name changes, and non-Latin transliteration variants all produce false positives or false negatives
    Advanced search (name + institution/DOI) Narrowing a large name-search result set when you already know the affiliation or a recent publication Still relies on metadata being complete and consistently formatted at source
    ORCID iD lookup (direct resolution) Confirming or citing a specific, already-known researcher with certainty Requires you to already have the iD — it does not help discovery
    Authenticated iD collection (OAuth sign-in) Publishers, funders, and repositories capturing a verified iD at the point of submission or registration Depends on the researcher having, and choosing to use, an existing ORCID account

    Answer-first Q&A

    How do you look up someone’s ORCID iD?

    Go to the ORCID Registry at orcid.org and enter the person’s name in the search bar. If the result list is long, use advanced search to add their institution, a recent publication DOI, or a keyword from their field to narrow the candidates to the correct individual.

    Is an ORCID iD public?

    Yes. An ORCID iD number is always publicly visible and resolvable, regardless of a researcher’s other privacy settings. The surrounding biographical and activity data on the record, however, is controlled by the researcher and can be restricted to “only me” or “trusted parties” only.

    What does ORCID stand for?

    ORCID stands for Open Researcher and Contributor ID. It refers both to the not-for-profit organisation that operates the registry and to the sixteen-character persistent identifier it issues to individual researchers and contributors.

    Why does an ORCID name search return too many results?

    A name search returns too many results because a name is not a unique key — thousands of active researchers can share an identical given-and-family-name combination. Without a persistent identifier or a narrowing filter such as institution or DOI, there is no reliable way to isolate one specific individual from the list.

    Implications for institutions and publishers

    For research administrators, the practical lesson is that name-search UIs should be treated as a discovery aid for humans, never as an automated matching key inside institutional systems. Repository, CRIS, and manuscript-submission integrations that silently attach ORCID iDs based on a name-string match will misattribute records whenever two researchers share a name — and will silently fail to link records for anyone who has changed their name or whose name has been transliterated inconsistently across source systems.

    This is also why publisher metadata increasingly requires an authenticated iD at submission rather than accepting a name-matched one after the fact: it shifts verification to the point of origin, where the researcher is present to confirm it. The same logic underpins CASRAI’s originated CRediT contributor role taxonomy, which assigns specific contribution roles to named authors: role attribution is only meaningful if the author behind the name is unambiguous. CASRAI originated the CRediT taxonomy in 2014; the standard is now stewarded by NISO as ANSI/NISO Z39.104-2022, and pairing CRediT roles with an authenticated ORCID iD closes the same disambiguation gap that a name search cannot.

    Persistent identifiers such as ORCID, alongside institutional identifiers like ROR, are converging with standards such as DataCite and CrossRef metadata schemas to make identity resolution a structural property of the scholarly record rather than a search-time guess. As adoption deepens, expect fewer systems to expose name search as a primary discovery method at all, reserving it for the narrow case of an initial, informal lookup before an authenticated connection is made.

    Institutions building or reviewing authorship workflows, or mapping contributor roles under the CRediT taxonomy, should treat ORCID iD collection — not name matching — as the disambiguation control of record.

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

  • ORCID Membership: Consortium vs Direct Guide

    ORCID membership is free only for individual researchers; institutions that want to integrate ORCID into their systems must pay an organisational fee, either directly to ORCID Inc. or, at a discount, through a national or regional consortium. The choice between direct membership and consortium membership determines what an institution pays, which API scopes and integration support it gets, and whether it gains a voice in ORCID’s governance.

    ORCID membership is the paid organisational tier that lets an institution connect its own systems to the ORCID registry — reading and writing data to researcher records with permission — rather than simply relying on researchers’ free, individually held ORCID iDs.

    What is ORCID membership, and how is it different from free registration?

    Individual ORCID registration is, and always will be, free: any researcher can create a 16-digit ORCID iD at orcid.org/register in under a minute and use it for life. ORCID membership is a separate, paid tier for organisations — universities, publishers, funders, and service providers — that want to integrate ORCID data into their own institutional systems rather than rely on manual, researcher-entered information.

    Membership unlocks the ORCID Member API, which allows an institution’s research information system, repository or HR platform to read and, with the researcher’s permission, write data to the ORCID registry — publications, affiliations, grants and peer review activity. Without membership, an organisation can still search the public ORCID database and encourage “Sign in with ORCID” authentication, but it cannot programmatically update records at scale.

    ORCID Inc. reports more than 1,200 member organisations worldwide, made up of both direct members and institutions that joined through a consortium, spanning universities, publishers, funders, facilities and government agencies.

    What does direct institutional membership include?

    Direct membership means an institution contracts and pays ORCID Inc. directly, with no intermediary. Under ORCID’s published 2026 fee schedule, Basic direct membership costs US$4,775 a year for non-profit and government organisations (after a standard 20% non-profit discount) and US$5,975 for commercial organisations. Premium direct membership — which adds priority support, on-demand reporting and a customised onboarding — costs US$9,550 a year for smaller non-profit organisations (under US$200 million in annual revenue or funds) and rises to US$23,880 for larger non-profits above that threshold.

    Direct members manage their own ORCID integration: applying for membership, renewing annually, handling invoicing, and owning their API credentials without a consortium administrator in the loop. This suits institutions with in-house developer capacity that want a direct line to ORCID’s own support team and full control over procurement terms.

    • Standard application, renewal and invoicing handled directly with ORCID Inc.
    • Full Member API access to read and write ORCID record data with permission
    • Ability to negotiate specific procurement or legal requirements within ORCID’s standard framework
    • Additional integrations available at US$3,585 each per year

    What does consortium membership include, and how does it cut costs?

    Consortium membership is open only to non-profit and government organisations. A consortium lead — typically a national research infrastructure body — negotiates a single block agreement with ORCID and then apportions fees across member institutions, all of whom automatically receive Premium-equivalent access. In the UK, Jisc administers the national ORCID consortium, offering reduced membership costs plus UK-based technical and community support through a dedicated support site. Equivalent consortia operate elsewhere: the ORCID US Community is administered by Lyrasis, the Health Research Alliance runs a health-research-focused consortium with five premium API keys per member, and IReL administers the Irish Research eLibrary consortium.

    ORCID’s consortium fee table is tiered by both institutional budget size and the number of organisations in the consortium: a five-member consortium of small non-profits (under US$10 million annual budget) pays US$3,495 per member per year, falling to US$1,750 per member once the consortium reaches 60 or more members. Organisations in countries classified by the World Bank as Lower Income receive an 80% reduction on consortium fees, and Lower-Middle-Income organisations receive a 50% reduction, under ORCID’s Membership Equity Program — which also lowers the minimum consortium size from five to three organisations for a group’s first year.

    Consortium members gain two things direct members do not: a shared “community of practice” with peer institutions solving the same integration problems, and exclusive access to the Affiliation Manager tool, which lets non-technical staff add and update researcher affiliation data without a developer.

    Direct vs consortium: cost, API access and governance compared

    The headline trade-off is straightforward: consortium membership is cheaper and comes bundled with premium access and local support, but it hands administration to a third-party lead organisation; direct membership costs more but keeps the relationship — and the paperwork — entirely in-house.

    Factor Direct membership Consortium membership
    Who administers it ORCID Inc. directly A consortium lead (e.g. Jisc in the UK, Lyrasis for the ORCID US Community)
    2026 indicative cost US$4,775–US$23,880/year (non-profit, Basic to Premium) US$1,750–US$9,340/member/year, scaling down as consortium size grows
    Eligibility Any organisation type Non-profit and government organisations only
    API access level Basic or Premium (self-selected) Premium-equivalent, automatically
    Affiliation Manager tool Not included Included
    Local/community support ORCID’s own global support team Consortium lead’s national/regional support team
    Governance voice Eligible to stand for and vote in ORCID Board elections Eligible to stand for and vote in ORCID Board elections

    Institutional governance participation — nominating a representative for the ORCID Board and voting in annual Board elections — is a benefit of ORCID membership itself, not a differentiator between the two routes; both direct and consortium members hold this governance voice.

    Which route should an institution choose?

    For most universities and non-profit research organisations, joining an existing national or regional consortium is the more cost-effective starting point: it delivers premium API access, local implementation support and peer knowledge-sharing at a fraction of direct-membership pricing. Institutions in a country without an established consortium can use ORCID’s Membership Equity Program to form one with as few as three founding members in year one.

    Direct membership better suits organisations that are commercial (and therefore ineligible for a consortium), that need bespoke procurement or legal terms outside a consortium’s standard agreement, or that already run substantial in-house integration teams and prefer a direct relationship with ORCID’s support desk rather than a national intermediary.

    Research administration teams evaluating either route should confirm three things before signing: which access tier (Basic or Premium) the fee actually buys, whether a local consortium already exists for their jurisdiction, and whether their researcher information system vendor already holds member API credentials that could reduce the need for a separate institutional integration.

    Common questions about ORCID membership

    Does ORCID cost money?

    Individual ORCID registration is always free for researchers. Cost only applies at the organisational level: institutions pay an annual membership fee — starting around US$1,750 per member through a large consortium, or from roughly US$4,775 for direct non-profit membership — to integrate ORCID into their own systems.

    How much does it cost to register with ORCID?

    Registering for a personal ORCID iD costs nothing and takes under a minute at orcid.org/register. Institutional membership fees are separate and depend on the route chosen: direct membership is tiered by revenue, while consortium membership is tiered by both budget size and consortium membership count, per ORCID’s published 2026 fee schedule.

    What are the benefits of having institutional ORCID membership?

    Membership gives an institution Member API access to read and write trusted data — publications, affiliations, funding — directly into researcher ORCID records with permission, streamlining research information management, funder compliance reporting and automated CV generation for researchers.

    Implications for research administration

    As funders increasingly require ORCID iDs in grant applications and publishers embed them in submission workflows, institutional ORCID integration is shifting from optional to expected infrastructure. The consortium model has proven durable precisely because it converts a fixed, individually negotiated cost into a shared, scaling one — the more organisations that join a national consortium, the cheaper membership becomes for every existing member. Institutions weighing the decision should treat it as an infrastructure procurement choice tied to their research administration systems roadmap, not an isolated subscription decision.

  • medRxiv API: Endpoints, Limits and Use Cases

    The medRxiv API is a free, public REST interface — operated by openRxiv, the non-profit behind medRxiv and bioRxiv — that returns structured JSON or XML metadata for health-sciences preprints: titles, authors, abstracts, DOIs, dates, licences and subject categories. Developers query it by date range, by a fixed number of recent posts, or by a single DOI, with results paginated in batches of 100 via a cursor parameter. There is no API key requirement and no separate registration step.

    A preprint, in this context, is a complete but not-yet-peer-reviewed manuscript; the medRxiv API is the machine-readable route to the metadata that describes it, distinct from the full-text PDF/XML mining pipeline hosted separately on Amazon S3.

    What is the medRxiv API?

    The medRxiv API is a lightweight metadata service, not a search engine or a full-text repository. It shares its underlying infrastructure with the bioRxiv API — both are addressable via api.biorxiv.org or the medRxiv-branded mirror at api.medrxiv.org — because both preprint servers are co-managed by the same non-profit.

    medRxiv and bioRxiv are operated by openRxiv, a non-profit founded by Cold Spring Harbor Laboratory (CSHL), Yale University and BMJ, and funded by contributions including the Chan Zuckerberg Initiative, Imperial College London and Stanford University. This governance detail matters for developers assessing service continuity: the API is not a commercial product with an SLA, but a grant- and institution-funded public good, published under the same operational umbrella that screens and posts the preprints themselves.

    medRxiv API endpoints explained

    There are two distinct endpoint families. Confusing them is the most common integration mistake developers make, since both accept the same server, interval and cursor parameters but return different content.

    Endpoint Purpose Format
    api.medrxiv.org/details/[server]/[interval]/[cursor]/[format] Preprint metadata — title, authors, abstract, DOI, posting date, category, licence json or xml
    api.medrxiv.org/details/[server]/[DOI]/na/[format] Single-manuscript lookup by DOI json or xml
    api.biorxiv.org/pubs/[server]/[interval]/[cursor] Published-version linkage — which journal, when, and the published DOI json

    server takes the value medrxiv or biorxiv. interval accepts three forms: two YYYY-MM-DD dates separated by a slash; a plain number for the N most recent posts; or a number suffixed d for the most recent N days. cursor defaults to 0 and advances in steps of 100, matching the fixed page size medRxiv documents for both endpoint families.

    A working example: https://api.medrxiv.org/details/medrxiv/2020-03-21/2020-03-24/45 returns up to 100 medRxiv records posted in that window, starting from the 45th result. Each response includes a messages array reporting the cursor position and total count, which developers should use to drive pagination rather than hard-coding offsets.

    Rate limits, formats and bulk access

    medRxiv does not publish a numeric requests-per-second quota for the metadata API. In practice, the service is engineered around cursor-based pagination capped at 100 records per call, which itself throttles realistic usage patterns without a documented rate-limit header. Developers building high-volume harvesters should paginate sequentially rather than firing parallel requests, since the API is a shared public resource funded by academic and philanthropic contributions, not a commercially provisioned endpoint.

    For anything beyond metadata — full-text PDF and XML mining at scale — medRxiv explicitly separates that workload onto a dedicated Amazon S3 requester-pays bucket (s3://medrxiv-src-monthly), rather than serving it through the JSON API. This is a deliberate architectural boundary: the metadata API is for discovery and linkage, S3 is for bulk text and data mining (TDM), and mixing the two workloads against the wrong endpoint is the most common cause of developer friction.

    • Metadata endpoints return JSON (default) or XML in OAI-PMH format.
    • Bulk full-text files are delivered monthly as MECA-format zip packages containing manifest XML, full-text XML and PDF.
    • All preprints are permanently archived at Portico, independent of the live API.

    Practical use cases for developers

    The API’s realistic use cases cluster around discovery, linkage and bibliometrics rather than full-text analysis:

    • Systematic review screening — pulling all preprints in a date range and subject category to feed a title/abstract screening pipeline before formal database searches.
    • Publication-linkage tracking — using the /pubs/ endpoint to detect when a tracked preprint has since been formally published, and in which journal.
    • Institutional repository harvesting — research offices ingesting metadata for preprints affiliated with their institution to populate internal dashboards.
    • Bibliometric and disease-surveillance research — reproducing analyses of preprinting velocity by subject category, a pattern widely used during infectious-disease outbreaks.

    A minimal Python request against the details endpoint needs no authentication:

    import requests

url = "https://api.medrxiv.org/details/medrxiv/10d/0/json"
resp = requests.get(url, timeout=30)
data = resp.json()
print(data["messages"][0]["total"], "preprints in the last 10 days")

    The R package medrxivr (rOpenSci) wraps the same endpoints for R users who prefer not to handle pagination and JSON parsing directly.

    Answer-first Q&A

    Does medRxiv have a public API?

    Yes. medRxiv provides a free, unrestricted public API at api.medrxiv.org and api.biorxiv.org, returning JSON or XML preprint metadata by date range, recent-post count, or DOI. No API key or account is required, and the same infrastructure also serves bioRxiv metadata.

    What is the difference between the bioRxiv and medRxiv APIs?

    They are the same API distinguished only by a server parameter set to medrxiv or biorxiv. Both preprint servers are co-managed by openRxiv and share identical endpoint syntax, pagination and response schemas, though each server applies separate scope and screening policies to submissions.

    How do I cite a medRxiv preprint retrieved via the API?

    Cite the preprint by its DOI, exactly as medRxiv’s own guidance specifies: author names, year, title, and “medRxiv doi: 10.1101/…”. For a specific revision, append the version-specific URL, since each version keeps the same DOI but a distinct version suffix in its address.

    Does medRxiv have an Impact Factor?

    No. medRxiv’s own FAQ states plainly: “medRxiv is not a journal and so it has no Impact Factor.” Metadata pulled via the API includes posting dates, categories and licences, but never a journal-style Impact Factor field, because none exists for preprints on the server.

    Implications and what’s next

    For institutions and research administration offices, the practical implication is that medRxiv metadata is genuinely free to harvest at scale for compliance dashboards, preprint-to-publication tracking, and REF-style output monitoring — no licensing negotiation is required, unlike many commercial bibliographic APIs. The trade-off is that developers must build their own resilience: there is no documented rate-limit contract, no SLA, and no formal versioning notice channel beyond the help pages themselves.

    The clearest forward risk is architectural drift rather than access restriction: because the API is maintained by a philanthropically funded non-profit rather than a commercial vendor, integrations should be built defensively — using the documented cursor pagination rather than assumptions about page size, and routing bulk text-mining workloads to the S3 bucket rather than the JSON endpoints, which is where undocumented load is most likely to cause friction for openRxiv’s infrastructure over time.

  • How bioRxiv Versioning Works (v1, v2, v3)

    bioRxiv versioning works by assigning every preprint a version number starting at v1 on first posting; authors can submit revisions at any time before journal acceptance, each becoming v2, v3 and so on under the same DOI, with every prior version preserved and independently citable via the “Info/History” tab. Unlike a journal correction process, there is no editor gatekeeping a revision, and nothing is ever deleted from the record.

    A bioRxiv version is a distinct, permanently archived snapshot of a preprint’s PDF, HTML and XML files, numbered sequentially (v1, v2, v3…) and linked to one persistent DOI that never changes across revisions. Understanding this versioning system — what triggers a new version, what stays fixed, and how to cite a specific one — matters for authors tracking revision history and readers who need to know exactly which version of a claim they are reading.

    What happens when a preprint first posts as v1?

    When a manuscript clears bioRxiv’s screening process — typically within 72 hours of submission, according to bioRxiv’s own FAQ — it is posted as version 1 (v1). The PDF appears first; full-text HTML and XML conversion follows 24–48 hours later.

    Each version, from v1 onward, is independently available in PDF, HTML and XML — the XML format exists for text-mining and machine-readable indexing, a detail most competing explainers omit. Once v1 is live, it is immediately assigned a DOI (via Crossref) and indexed by Google Scholar, Europe PubMed Central and the Preprint Citation Index connected to Web of Science: v1 is citable and part of the permanent scientific record from the moment it posts, not a provisional draft.

    How do authors submit a v2 or later revision?

    Authors submit revisions through the “Submit a Revision” option in their bioRxiv Author Area, locating their existing submission ID and selecting “Submit a revised manuscript.” bioRxiv’s policy states a manuscript “can be revised at any time until it is published in a journal” — there is no fixed revision window and no limit on the number of versions.

    The revision mechanism is intended for substantive changes: new datasets, re-analyses, expanded discussion, or additional supplemental information. A revision is posted under the same DOI, and — critically — the prior version is not overwritten. It remains permanently accessible through the article’s Info/History tab, so a reader can always compare what changed between v1 and v2, or v2 and v3.

    One detail rarely covered elsewhere: if a preprint was originally submitted indirectly via a journal’s own pipeline (journal-to-bioRxiv, or “J2B”), the corresponding author must first register a bioRxiv account using the same email address used at journal submission before they can access the Author Area to file a revision.

    Does the DOI change between versions, and how do you cite one?

    The DOI stays fixed across every version of a bioRxiv preprint. v1, v2 and v3 of the same manuscript all resolve through one DOI — a reader following an older citation lands on whatever version is current, with the option to step back through history.

    To cite a specific version rather than “whatever is current,” bioRxiv appends a version-specific URL to the DOI. Its FAQ gives this exact pattern:

    Element Format Example
    Standard DOI citation doi: 10.1101/[identifier] doi: 10.1101/2019.12.11.123456
    Version-specific citation DOI + version-specific URL doi: 10.1101/2019.12.11.123456 version 2, https://www.biorxiv.org/content/10.1101/2019.12.11.123456v2

    This matters for reference managers such as EndNote: the DOI field should carry the persistent identifier, while the version number belongs in the URL or a note field if the citing author wants to pin the exact revision read, rather than whichever version happens to be live later.

    One exception: if a revision alters the manuscript so substantially that bioRxiv considers it a genuinely different article, the author must submit it as a new manuscript — which receives its own, separate DOI rather than becoming v2 of the original.

    What does NOT require a new version?

    Three specific cases are worth flagging because they trip up first-time bioRxiv authors and are absent from most general explainers:

    • Metadata typos. If the title, author names, affiliations or abstract in the submission form contain an error but the PDF is correct, bioRxiv auto-replaces the site metadata with text extracted from the PDF within roughly 48 hours — authors are told not to submit a full revision solely to fix this.
    • Author name changes. bioRxiv permits a “silent” first/last name update — for example after a legal name change — by direct email request, without a new version or correction notice. This excludes author removal or reordering, which need a standard revision.
    • Supplemental-file-only changes. If only supplemental files change, bioRxiv still requires them submitted together with the article file as part of a new version; a supplemental-only upload cannot be filed alone.

    What happens if an author withdraws a preprint?

    bioRxiv preprints cannot be deleted once posted, because each version carries a DOI and is indexed externally by Google Scholar and Crossref, creating a permanent footprint independent of bioRxiv’s own servers. If authors no longer stand behind their findings, the remedy is a formal withdrawal, not removal.

    To withdraw, the corresponding author uses “Submit a Withdrawal Statement” inside the same Author Area used for revisions. A withdrawal adds a “Withdrawn” watermark to the PDF of every version ever posted and posts an explanatory statement on the article page — but the original manuscript remains viewable via the Info/History tab. It is a labelled correction, not an erasure. bioRxiv notes outright removal happens only in “extremely rare cases,” for legal or safety reasons.

    Once a preprint is published in a peer-reviewed journal, no further author action is usually needed: bioRxiv automatically adds a link to the published version within approximately two weeks, and all preprint versions — v1 through the final revision — remain live alongside it.

    Common questions about bioRxiv versioning

    Can I upload a new version or replace a bioRxiv preprint?

    Authors cannot replace or delete a posted version, but they can add a new one. Using “Submit a Revision” in the Author Area at any point before journal acceptance creates the next sequential version (v2, v3…) while every earlier version stays permanently visible in the Info/History tab.

    Why does bioRxiv take so long to post a new version?

    Both initial posting and revisions go through the same screening step, which usually completes within 72 hours. Delays typically occur over weekends or holidays, or when a submission needs extra scrutiny for scope, plagiarism or safety-related content before the new version is approved.

    Does bioRxiv count as published once it has multiple versions?

    No. Additional versions do not confer peer-reviewed status. bioRxiv is explicit that it “is not a journal” and has no Impact Factor; every version, however many revisions deep, carries the standard disclaimer that the content has not been certified by peer review.

    Are previous bioRxiv versions still readable after a revision posts?

    Yes. Every prior version remains permanently accessible through the Info/History tab on the preprint’s landing page after a new version is submitted, so readers can compare v1 against later revisions rather than losing access to earlier text.

    Implications for research administrators and institutions

    For institutions tracking preprint outputs in repository or CRIS systems, the persistent-DOI-plus-version model means a single DOI can legitimately correspond to several distinct texts over time. Metadata harvesting workflows that snapshot “the” abstract or author list at ingestion risk becoming stale if a later version changes those fields — administrators should record which version number was harvested, not just the DOI.

    For funders, the NIH has stated it “encourages investigators to use interim research products, such as preprints, to speed the dissemination and enhance the rigor of their work,” and preprints of NIH-funded studies are indexed in PubMed regardless of version count. Citing the version actually reviewed — using the version-specific URL pattern above — gives reviewers an unambiguous audit trail rather than a moving target.

    As preprint volume grows, the version history itself is becoming part of the evidentiary record: it documents how a finding evolved in response to community comment before formal peer review.

  • bioRxiv Microbiology: 2026 Subject Growth

    bioRxiv’s microbiology collection holds more than 41,000 preprints as of July 2026, making it the platform’s third-largest subject area behind neuroscience (over 90,000) and bioinformatics (nearly 43,000). Together, these three fields account for close to two-fifths of every preprint ever posted to bioRxiv since its 2013 launch — a concentration that says as much about where biology’s fastest-moving fields are as it does about the platform itself.

    bioRxiv is a free, non-profit preprint repository for the biological sciences, now operated by openRxiv, on which authors post manuscripts before or independent of journal peer review, sorted into 27 subject-specific collections spanning everything from paleontology to synthetic biology.

    What is bioRxiv, and how are preprints organised by subject?

    bioRxiv was co-founded by John Inglis and Richard Sever in November 2013 as an open-access preprint repository hosted by Cold Spring Harbor Laboratory. In March 2025, bioRxiv and its clinical-sciences counterpart medRxiv transferred to openRxiv, a newly formed non-profit created specifically to steward both platforms, as reported by Science.

    Every submission is placed into one of 27 subject collections at the point of posting. There is no fee to submit to bioRxiv, and authors self-select the collection that best matches their manuscript. This subject taxonomy is what makes volume comparisons across fields possible — and what this analysis draws on directly.

    One structural exception worth noting: the Epidemiology collection is now closed to new submissions following the completion of bioRxiv’s clinical-research pilot project, meaning its growth curve has effectively flattened while other collections continue to expand.

    How does bioRxiv microbiology compare to neuroscience and other subjects by volume?

    Based on a live count of bioRxiv’s own subject-collection pages taken on 3 July 2026, neuroscience is the platform’s largest single collection at 90,290 preprints — a 19.4% share of the roughly 465,700 preprints posted across all 27 collections to date. Bioinformatics follows at 42,825 (9.2%), with microbiology close behind at 41,133 (8.8%).

    Cell biology, evolutionary biology, genomics and biophysics round out the next tier, each holding between roughly 21,000 and 26,000 preprints. At the other end of the scale, paleontology (678) and clinical trials (138) remain niche collections by comparison, while epidemiology’s 2,067 total is now largely fixed given its closure to new submissions.

    Full ranking of bioRxiv’s largest subject collections

    Rank Subject collection Cumulative preprints Share of total
    1 Neuroscience 90,290 19.4%
    2 Bioinformatics 42,825 9.2%
    3 Microbiology 41,133 8.8%
    4 Cell Biology 25,753 5.5%
    5 Evolutionary Biology 24,737 5.3%
    6 Genomics 22,868 4.9%
    7 Biophysics 21,837 4.7%
    8 Ecology 20,284 4.4%
    9 Cancer Biology 18,775 4.0%
    10 Biochemistry 18,098 3.9%

    Source: CASRAI analysis of live bioRxiv subject-collection article counts, recorded 3 July 2026. These are cumulative totals since bioRxiv’s 2013 launch, not annual submission rates, so they reflect sustained field-level adoption of preprinting rather than a single year’s activity.

    Microbiology’s position just behind bioinformatics is notable given how differently the two fields work: bioinformatics preprints are often fast, computational and low-cost to produce, while microbiology preprints typically follow wet-lab experimental cycles. That microbiology has nonetheless built a corpus within a few thousand papers of bioinformatics points to strong, sustained preprinting culture within microbiology specifically — likely reinforced by the field’s pandemic-era experience with rapid-dissemination norms.

    Why does subject-level concentration matter for research administrators?

    For institutional leaders and research-administration teams, subject-level preprint concentration is a proxy for where scholarly communication norms are shifting fastest. A field with tens of thousands of preprints has, in effect, normalised pre-peer-review dissemination as a routine step in its publication workflow — with direct implications for how institutions track outputs, credit early dissemination in tenure and promotion review, and advise researchers on preprint policy.

    • Grant and promotion committees increasingly need clear policy on whether preprints count as citable outputs, particularly in high-volume fields like neuroscience and microbiology.
    • Research offices supporting microbiology, bioinformatics or genomics groups should expect preprint-first workflows to already be the norm, not the exception, among active researchers.
    • Fields with low preprint volume (pathology, zoology, clinical trials) may need different guidance, since preprinting culture there remains comparatively immature.

    This is also a live concern for research administrators and institutional leaders tracking how open-research norms diffuse unevenly across disciplines — subject-level data of this kind gives institutions a concrete basis for that assessment, rather than relying on anecdote.

    Common questions about bioRxiv preprints

    Is bioRxiv a preprint server?

    Yes. bioRxiv is a dedicated preprint server for the biological sciences, distributing manuscripts before or alongside formal peer review. It is operated by openRxiv, a non-profit created in 2025 specifically to run bioRxiv and medRxiv, and hosts subject collections spanning microbiology, neuroscience, genomics and 24 other biology-related fields.

    Can anyone submit to bioRxiv?

    Authors can deposit a manuscript in draft or final form provided it concerns a relevant scientific field, is unpublished at the time of submission, and all co-authors have consented. Authors must first register on the platform. bioRxiv screens submissions for basic scope and ethical compliance before posting, but does not conduct peer review.

    How much does it cost to publish in bioRxiv?

    There is no fee to submit a preprint to bioRxiv. This free-to-post model is a key driver of its growth across every subject collection, including the microbiology and neuroscience volumes analysed above, since it removes the cost barrier that applies to many open-access journal publication routes.

    Does bioRxiv count as published?

    A bioRxiv preprint is not equivalent to a peer-reviewed publication. It establishes a timestamped, citable public record of the work, and many journals allow later submission of the same manuscript, but it has not undergone formal peer review at the point of posting. Institutions and funders vary in how they weight preprints in assessment.

    Implications and outlook for scholarly communication

    The concentration of preprint volume in neuroscience, bioinformatics and microbiology is likely to persist rather than reverse. These fields combine large, active researcher populations with production cycles well suited to rapid dissemination, and none shows structural barriers comparable to epidemiology’s now-closed pilot pathway.

    For research-administration teams, the practical takeaway is to treat preprint-volume data by subject as a planning input: policy on preprint citation, researcher guidance, and repository integration should be calibrated to each discipline’s actual adoption level rather than applied uniformly across an institution’s full research portfolio.

  • PNAS bioRxiv Direct Submission: How B2J Works

    The PNAS bioRxiv submission pathway runs through bioRxiv’s own bioRxiv-to-journal (B2J) transfer tool, which sends manuscript files, figures and author metadata straight from a preprint’s “Author Area” into a partner journal’s editorial system. PNAS Nexus, the open-access companion journal published with Oxford University Press, is a listed B2J partner; the flagship PNAS journal instead accepts bioRxiv preprints under its standard “posting is permitted” policy, handled through ordinary manual submission. Nature and eLife each use a third and fourth mechanism again — this guide maps all of them.

    Direct submission, in the strict bioRxiv sense, means B2J: an automated transfer of files and metadata that removes the need to re-upload a manuscript at the receiving journal. That is a narrower, more specific claim than “the journal accepts preprints,” and conflating the two is the most common error in advice about preprint-to-journal workflows.

    Does PNAS accept direct submission from bioRxiv?

    Yes, but the route depends on which PNAS title is involved. PNAS’s Standard License Terms state that authors retain “the right to post the manuscript on preprint servers such as arXiv or bioRxiv,” and its editorial policies confirm that posting on preprint servers “is permitted and will not affect editorial consideration.” That is a preprint-tolerance policy, not a file-transfer mechanism.

    For an actual B2J connection — where bioRxiv pushes the manuscript and metadata into the journal’s submission system — the relevant partner on bioRxiv’s own list is PNAS Nexus, the fully open-access companion journal the National Academy of Sciences launched with Oxford University Press in 2022. Authors submitting to the flagship PNAS still upload independently and disclose the bioRxiv DOI in their cover letter or submission form.

    How does bioRxiv’s B2J transfer system actually work?

    bioRxiv describes B2J as a service that “can save authors time in submitting papers to journals or peer review services by transmitting their manuscript files and metadata directly from bioRxiv.” Authors do not re-enter author lists, funding statements or figure files; the receiving journal’s system pulls them from the preprint record.

    bioRxiv’s live Submission Guide lists 192 partner journals and peer-review services participating in B2J at the time of this analysis (mid-2026), spanning the PLOS family, EMBO’s three journals, Cell Press titles such as Cell Reports and Cell Genomics, the Royal Society’s journals, AAAS’s Science-family titles (Science Advances, Science Immunology, Science Signaling, Science Translational Medicine), Genetics Society journals, and independent review services including Review Commons.

    • Confirm the preprint version you want to transfer — revisions keep the same DOI, so specify the version-specific URL if it matters.
    • Select a reuse licence on bioRxiv (CC BY, CC BY-NC, CC BY-ND, CC BY-NC-ND or CC0) before transfer, since this travels with the metadata.
    • Check the receiving journal’s own preprint-disclosure requirement — B2J moves files, but editorial policy compliance remains the author’s responsibility.
    • Verify funder mandate compatibility (for example NIH Public Access or cOAlition S requirements) before relying on the preprint version alone for compliance.

    bioRxiv itself is operated by openRxiv, described on its own Submission Guide as “a non-profit organization dedicated to advancing science communication” — a distinct entity from any single receiving journal, which is why B2J participation is a per-journal opt-in list rather than a universal feature.

    How does Nature handle bioRxiv preprints?

    Nature and most Nature-branded journals treat a bioRxiv posting as compatible with submission, not as prior publication, so authors can submit a manuscript that already exists as a bioRxiv preprint. Unlike PNAS Nexus, however, neither the flagship Nature journal nor its major sister titles appear on bioRxiv’s public B2J partner list, so there is no automated file transfer from bioRxiv into Nature’s own submission system as of this analysis.

    The practical route is the standard one: submit through the journal’s own online system and disclose the preprint DOI in the cover letter. Springer Nature separately runs “In Review,” a partnership with Research Square that posts a preprint alongside transparent, published peer-review reports for participating journals — a related but functionally different bridge from bioRxiv’s B2J, since it originates on the journal side rather than the preprint-server side.

    How does eLife’s preprint-review model differ?

    eLife’s relationship with bioRxiv is the tightest of the three, but it is not a simple file-transfer either. eLife announced its bioRxiv-integrated transfer option in 2017, letting authors “upload a preprint to bioRxiv first and then transfer their files for consideration by eLife.” In December 2020, eLife announced it would require all new submissions to be posted as preprints on bioRxiv, medRxiv or an equivalent server before review — a policy shift reported by Science/AAAS at the time.

    Since its 2023 “Publish, Review, Curate” model, eLife no longer issues accept/reject decisions after review. Every manuscript it reviews is published as a Reviewed Preprint — the bioRxiv (or medRxiv) posting itself, plus public peer reviews and an eLife Assessment summarising significance and evidence strength. The preprint version and the eLife editorial layer stay linked rather than being replaced by a separate “Version of Record.”

    Journal / publisher Preprint policy Mechanism from bioRxiv Notable detail
    PNAS (flagship) Posting permitted; not prior publication Manual submission; author discloses DOI Reviewers may see the preprint version directly
    PNAS Nexus Same NAS preprint stance Listed bioRxiv B2J partner Open-access companion journal, launched with OUP in 2022
    Nature (and most sister titles) Preprints not treated as prior publication Standard submission; not on bioRxiv’s B2J list Separate “In Review” service via Research Square for some titles
    eLife Preprint posting required since Dec 2020 Author-initiated transfer from bioRxiv Author Area (since 2017) Since 2023, all reviewed papers are published as bioRxiv-linked Reviewed Preprints

    Common questions on bioRxiv journal submission

    Does PNAS allow bioRxiv?

    Yes. PNAS’s Standard License Terms and editorial policies explicitly state that posting on preprint servers such as arXiv or bioRxiv is permitted and does not count as prior publication. Authors must disclose the preprint and its DOI during submission, and the flagship title is submitted manually rather than via bioRxiv’s automated B2J transfer.

    Who owns bioRxiv?

    bioRxiv is operated by openRxiv, which describes itself as “a non-profit organization dedicated to advancing science communication.” It is independent of any single publisher, which is why individual journals — including flagship PNAS and Nature — must separately opt in to its B2J transfer list rather than automatically inheriting it.

    Is eLife a preprint?

    Not exactly. eLife is a journal whose reviewed output is published as a Reviewed Preprint — the underlying bioRxiv or medRxiv posting plus eLife’s public peer reviews and an eLife Assessment. Since its 2023 model change, eLife does not issue a separate accept/reject “Version of Record”; the linked preprint remains the article of record.

    How long does a bioRxiv submission take?

    bioRxiv’s own FAQ states manuscripts are screened and typically post within hours of submission, with full-text HTML and XML conversion following one to two days later. This screening checks for offensive or non-scientific content and biosecurity risk, not scientific validity — bioRxiv preprints are explicitly not peer-reviewed before posting.

    What this means for authors and research offices

    For corresponding authors, the practical takeaway is definitional precision: check whether a target journal is a bioRxiv B2J partner (automated transfer) or merely preprint-tolerant (manual submission plus disclosure) before assuming a “direct” route exists. The two are not interchangeable, and the difference determines whether re-uploading files is necessary.

    For research administrators and institutional research offices tracking author compliance across preprint and published versions, the distinction also affects funder-mandate reporting: a bioRxiv posting satisfies green open-access requirements under policies such as those referenced by cOAlition S signatories, independent of whether the receiving journal later uses B2J or a manual route. Institutions monitoring this pipeline should treat “preprint accepted” and “direct B2J transfer available” as two separate checklist items, not one.

    Journal-side preprint bridges will likely keep diverging rather than converging: bioRxiv’s B2J list continues to add peer-review services (such as Review Commons) alongside traditional journals, while eLife’s Reviewed Preprint model and Springer Nature’s In Review service represent journal-initiated alternatives built for transparency rather than upload convenience. Authors and research offices should expect to track policy pages per title rather than assume a single universal standard.