Registering a Crossref DOI is not a one-time form submission. It is an ongoing metadata relationship: a Crossref member registers a record, that record has to carry enough metadata to actually be useful (not just to resolve), and the member is expected to keep it current as the work changes state — from accepted manuscript, to published version of record, to any later correction. This guide walks through what a publisher or repository actually submits, the mechanisms available for submitting it, and the timing rules that govern registration and updates, based directly on Crossref’s own documentation.
Who this applies to
Crossref is one of several DOI registration agencies operating under the International DOI Foundation, and the one scholarly publishers overwhelmingly use for journal articles, books, conference proceedings, preprints, and grants. Membership is not limited to traditional journal publishers — university presses, learned societies, preprint servers, and other content-owning organizations that produce citable scholarly outputs can join and register DOIs directly. Organizations whose primary output is research data rather than narrative scholarly content more often register through DataCite instead; see Crossref vs. DataCite for how the two agencies’ scope and member bases differ. Everything below describes the Crossref-specific deposit workflow.
Step 1: Choose a deposit method
Crossref’s own guidance on choosing a content registration method groups the options into two categories, and which one a member uses is mostly a function of how much volume they register and whether they already have a metadata-producing system in place.
Helper tools (for low volume or no in-house XML capability)
- Web Deposit Form — an online form covering journals, books, conference proceedings, reports, and dissertations. A person fills in the metadata fields directly and Crossref converts the input to schema-compliant XML behind the scenes.
- Metadata Manager — a guided-form tool, principally used for registering journal articles and grant records.
- OJS (Open Journal Systems) plugin — a Crossref XML export plugin for publishers running the open-source OJS platform, which generates and submits the deposit automatically from the journal’s existing article records.
Direct XML deposit (for higher volume or an existing metadata pipeline)
- Admin Tool upload — manually uploading a prepared XML file through Crossref’s web-based admin interface.
- HTTPS POST — submitting XML programmatically, which is what most publishers with an established production system (or a service provider acting on their behalf) use for routine, automated registration.
Whichever method is used, what actually reaches Crossref is the same thing: an XML document — a Crossref deposit XML file — formatted against Crossref’s metadata input schema. The helper tools exist to produce that XML for members who don’t want to write it by hand; they don’t change what has to be in it.
Step 2: Build the metadata against the right schema version
Crossref versions its metadata input schema, and multiple versions remain valid for deposit at any given time — members are not forced onto a new version the moment one ships, but Crossref’s schema versions documentation is the authoritative source for which versions are currently accepted and which is current. Anyone setting up a new deposit pipeline should build against the current version rather than an older one a legacy system happens to still use, since older accepted versions exist for backward compatibility, not as a recommended starting point. Grants records are the one major exception: they use a separate, dedicated schema rather than the general metadata input schema used for journal articles, books, conference proceedings, and most other content types.
Step 3: The minimum a record needs to actually resolve and function
A DOI only does its job — taking a reader from a persistent identifier to the actual content — if the deposit includes, at minimum, the elements that make resolution and basic discovery possible:
- The DOI itself, in the format the member is registering it under (typically a member-specific prefix plus a suffix the member controls).
- A resource URL — the live landing-page URL that the DOI will resolve to. This is what Crossref’s resolver actually uses; without it the DOI has nothing to point at.
- A title for the work.
- A publication date (at minimum a year; month and day where known).
Beyond that structural minimum, Crossref’s schema supports a much larger set of fields that are not strictly required for a DOI to resolve but are required, in practice, for the record to be useful to the rest of the scholarly infrastructure that depends on Crossref metadata — discovery tools, citation linking, funder and institutional reporting, and Crossref’s own value-added services:
- Author/contributor names and affiliations — without these, a record is effectively invisible to author-level discovery and to systems (including ORCID-integrated workflows) that match works to people.
- Journal/container identifiers — an ISSN and journal title for journal content, or equivalent container metadata (ISBN, series title) for books and proceedings.
- References — the reference list, submitted as structured metadata rather than free text where possible, is what powers Crossref’s cited-by linking between records. A record with no references contributes nothing to that citation graph even if it is itself cited by others.
- Funding information — funder names and grant/award identifiers, matched against the Crossref Funder Registry, which is what makes a work discoverable by funder and award number in downstream systems.
- License URL and usage rights — machine-readable license information (relevant to open access compliance checking).
- Abstract — optional but widely deposited, since it materially improves discoverability in tools that index Crossref metadata.
- ORCID iDs for authors, where the author has one — improves disambiguation and lets the work flow automatically into an author’s ORCID record when the author has authorized that connection.
Exactly which fields are mandatory versus optional is set at the record-type level in Crossref’s schema (a journal article, a book chapter, and a dataset record don’t require identical field sets) — members implementing or auditing a deposit pipeline should check the field-level requirements for their specific content type directly against Crossref’s schema library and markup guide rather than assume a single universal list, since the field set genuinely differs by content type.
Step 4: Registering before publication — pending publications
Crossref supports registering a DOI before a work is formally published, through what it calls a pending publication. This lets a publisher create the DOI and deposit basic metadata as soon as a manuscript is accepted, ahead of the full formal metadata that comes with the version of record — useful for citing accepted-in-press work, and for journals that want a stable, citable identifier available before final publication. A pending-publication DOI initially resolves to a landing page describing the item’s pending status, not to the final content.
Critically, that transition is not automatic. Once the work is actually published, the publisher has to separately register the full formal metadata for that same DOI so it resolves to the real content instead of continuing to point at the pending-publication landing page. Skipping that second registration step is a common and avoidable failure mode — the DOI keeps working, but keeps sending readers to a placeholder page indefinitely.
Step 5: Updating metadata after the initial deposit
Crossref’s own guidance on updating your metadata is direct about a point that trips up a lot of new depositors: metadata updates are not automatic, ever. Nothing about Crossref’s infrastructure watches a publisher’s website and re-syncs a record when the underlying content changes — title corrections, added funding information, an updated reference list, a name change, a retraction notice, a new license — all require the publisher to actively re-deposit.
Two mechanical details matter here:
- An update deposit replaces the whole record, not just the changed fields. Crossref’s update process overwrites the existing metadata with whatever is submitted in the update deposit, and any field not included in that update deposit gets nulled out — it does not simply retain the old value. A partial update built by hand, containing only the fields someone thinks changed, will silently wipe every field left out. The safe pattern is to always submit the complete, current record on every update, not a diff.
- There is no fee for updating an existing record. Registration of new content carries a per-DOI fee under most Crossref membership tiers; correcting or enriching an already-registered record does not.
Step 6: Verifying the deposit actually worked
Submitting a deposit is not the same as confirming it succeeded. Crossref processes deposits asynchronously and returns a submission log/depositor report indicating whether each record in a batch was accepted or rejected, and why. Crossref’s verify your registration guidance and its depositor reports are the mechanism for catching schema-validation failures, duplicate-DOI conflicts, or malformed records before they become an unnoticed gap in a publisher’s registered output — a deposit pipeline that only checks the initial HTTP response and never reviews the resulting report can miss silent rejections.
A practical timing summary
| Event | What to submit | When |
|---|---|---|
| Manuscript accepted, not yet published | Pending-publication metadata (title, authors, basic identifiers) | As soon as acceptance is final, if using pending publications |
| Formal publication (online-first or version of record) | Full metadata record: title, DOI, resource URL, publication date, authors, references, funding, license, ISSN/container info | At or immediately after publication — not deferred, since the DOI won’t resolve to real content until this deposit happens |
| Any subsequent change (correction, new funder info, retraction, license change) | Complete, current record — not a partial diff | As soon as the change is known; there is no batching requirement, but delay means the public record stays wrong in the meantime |
| After any deposit | N/A — review the depositor report/submission log | After every batch, to catch rejections before they go unnoticed |
How this connects to other Crossref-dependent infrastructure
Deposit quality has downstream consequences beyond DOI resolution. Reference metadata feeds Crossref’s cited-by linking; author and ORCID metadata feeds researcher-level discovery; funder metadata feeds funder and institutional reporting workflows; and members participating in Crossref’s Similarity Check service contribute their full-text content to the corpus that service screens against. A registration pipeline that only clears the minimum resolution requirements (DOI, URL, title, date) technically satisfies Crossref’s schema but leaves most of that downstream value on the table — which is why Crossref’s own documentation consistently frames richer metadata (references, funding, ORCID iDs, abstracts) as a strong practical expectation of active membership, not just an optional nicety.
Frequently asked questions
Do repositories deposit metadata to Crossref the same way publishers do?
Mechanically, yes — a repository that is a Crossref member (for example, a preprint server or an institutional repository registering DOIs for reports or theses) uses the same deposit methods and schema described above. The practical difference is usually in which fields are populated: a preprint deposit, for instance, typically won’t yet have the full reference list or final version-of-record metadata a published journal article carries, and may later need an update deposit once a formal published version exists and needs to be linked.
What happens if a required field is missing from a deposit?
Crossref’s schema validation rejects records that don’t meet the structural requirements for their content type; the rejection reason is returned in the submission log. This is why checking the depositor report after every batch matters — a rejected record does not register a DOI at all, and a missed rejection can leave content unregistered indefinitely without anyone noticing.
Can a publisher change the resource URL a DOI points to later?
Yes — updating the resource URL is one of the more common reasons for an update deposit, for example when a publisher migrates platforms or restructures article URLs. Since Crossref’s resolver only knows what the most recent deposit told it, an update is required any time the actual landing-page URL changes, or the DOI will continue resolving to a dead or incorrect link.
Is XML the only way to deposit metadata with Crossref?
XML is what Crossref’s schema is defined in and what every deposit method ultimately produces, but a publisher doesn’t have to write XML by hand — the web deposit form, Metadata Manager, and OJS plugin all generate compliant XML from a simpler input interface. Direct XML deposit (via the admin tool or HTTPS POST) is aimed at publishers with higher volume or an existing production pipeline that can generate the XML programmatically.
Related CASRAI resources
- Crossref DOI — what the identifier itself represents
- Crossref deposit XML — the file format underlying every deposit method above
- Pending publication (Crossref) — registering a DOI ahead of formal publication
- DOI Registration Agency — how the federated DOI system works and where Crossref fits
- Crossref vs. DataCite — choosing the right registration agency
- ISSN — the journal-level identifier required alongside journal-article deposits
- Author Guidelines: What Journals Require and How to Meet Them
