Latest blog posts
Martyn Rittman
2024 November 15

Research Integrity Roundtable 2024

For the third year in a row, Crossref hosted a roundtable on research integrity prior to the Frankfurt book fair. This year the event looked at Crossmark, our tool to display retractions and other post-publication updates to readers. Since the start of 2024, we have been carrying out a consultation on Crossmark, gathering feedback and input from a range of members. The roundtable discussion was a chance to check and refine some of the conclusions we’ve come to, and gather more suggestions on the way forward.

...Find out more
Dominika Tkaczyk
2024 November 06

How good is your matching?

In our previous blog post in this series, we explained why no metadata matching strategy can return perfect results. Thankfully, however, this does not mean that it’s impossible to know anything about the quality of matching. Indeed, we can (and should!) measure how close (or far) we are from achieving perfection with our matching. Read on to learn how this can be done! How about we start with a quiz? Imagine a database of scholarly metadata that needs to be enriched with identifiers, such as ORCIDs or ROR IDs.

...Find out more
Kornelia Korzec
2024 October 28

Update on the Resourcing Crossref for Future Sustainability research

We’re in year two of the Resourcing Crossref for Future Sustainability (RCFS) research. This report provides an update on progress to date, specifically on research we’ve conducted to better understand the impact of our fees and possible changes. Crossref is in a good financial position with our current fees, which haven’t increased in 20 years. This project is seeking to future-proof our fees by: Making fees more equitable Simplifying our complex fee schedule Rebalancing revenue sources In order to review all aspects of our fees, we’ve planned five projects to look into specific aspects of our current fees that may need to change to achieve the goals above.

...Find out more
Lucy Ofiesh
2024 September 24

Meet the candidates and vote in our 2024 Board elections

On behalf of the Nominating Committee, I’m pleased to share the slate of candidates for the 2024 board election. Each year we do an open call for board interest. This year, the Nominating Committee received 53 submissions from members worldwide to fill four open board seats. We maintain a balanced board of 8 large member seats and 8 small member seats. Size is determined based on the organization’s membership tier (small members fall in the $0-$1,650 tiers and large members in the $3,900 - $50,000 tiers).

...Find out more
  • Menu
search

Documentation

REST API Versions

REST API Versions

The Crossref REST API is versioned. You should always use the API version in your REST API requests.

Breaking changes

Any breaking changes will be released in a new API version. Breaking changes are changes that can potentially break an integration. Breaking changes include:

  • removing an entire operation
  • removing or renaming a parameter
  • removing or renaming a response field
  • adding a new required parameter
  • making a previously optional parameter required
  • changing the type of a parameter or response field
  • removing enum values
  • adding a new validation rule to an existing parameter
  • changing authentication or authorization requirements

Non-breaking changes

Any additive (non-breaking) changes will be available in all supported API versions. Additive changes are changes that should not break an integration. Additive changes include:

  • adding an operation
  • adding an optional parameter
  • adding an optional request header
  • adding a response field
  • adding a response header
  • adding enum values

Legacy version support

When a new REST API version is released, the previous API version will be supported for 24 more months following the release of the new API version. In exceptional circumstances, we may decide to extend this.

Specifying an API version

To be safe, You should always specify an API version in your requests.

For example:

https://0-api-crossref-org.libus.csd.mu.edu/v1/works?rows=0

However, as long as v1 of the API exists, requests that do not contain an API version in the request will default to v1.

Eventually, if you specify an API version that is no longer supported, you will receive a 400 error.

So, if version 1 of the API is ever retired, then requests to the API that do not contain a version number will fail with a 400 error.

Again, to be safe, you should include the API version in your requests.

Upgrading to a new API version

Before upgrading to a new REST API version, you should read the changelog of breaking changes for the new API version to understand what breaking changes are included and to learn more about how to upgrade to that specific API version. For more information, see “Breaking changes.”

Supported API versions

The following REST API versions are currently supported:

  • V1

Credits: This policy is adapted from the very short, clear and reasonable Github API policy

Page owner: Patrick Polischuk   |   Last updated 2022-December-01