Latest blog posts
Ginny Hendricks
2024 December 12

A progress update and a renewed commitment to community

Looking back over 2024, we wanted to reflect on where we are in meeting our goals, and report on the progress and plans that affect you - our community of 21,000 organisational members as well as the vast number of research initiatives and scientific bodies that rely on Crossref metadata. In this post, we will give an update on our roadmap, including what is completed, underway, and up next, and a bit about what’s paused and why.

...Find out more
Rosa Morais Clark
2024 December 09

A summary of our Annual Meeting

The Crossref2024 annual meeting gathered our community for a packed agenda of updates, demos, and lively discussions on advancing our shared goals. The day was filled with insights and energy, from practical demos of Crossref’s latest API features to community reflections on the Research Nexus initiative and the Board elections. Our Board elections are always the focal point of the Annual Meeting. We want to start reflecting on the day by congratulating our newly elected board members: Katharina Rieck from Austrian Science Fund (FWF), Lisa Schiff from California Digital Library, Aaron Wood from American Psychological Association, and Amanda Ward from Taylor and Francis, who will officially join (and re-join) in January 2025.

...Find out more
Lucy Ofiesh
2024 December 07

2024 POSI audit

Background The Principles of Open Scholarly Infrastructure (POSI) provides a set of guidelines for operating open infrastructure in service to the scholarly community. It sets out 16 points to ensure that the infrastructure on which the scholarly and research communities rely is openly governed, sustainable, and replicable. Each POSI adopter regularly reviews progress, conducts periodic audits, and self-reports how they’re working towards each of the principles. In 2020, Crossref’s board voted to adopt the Principles of Open Scholarly Infrastructure, and we completed our first self-audit.

...Find out more
Ed Pentz
2024 December 05

Summary of the environmental impact of Crossref

In June 2022, we wrote a blog post “Rethinking staff travel, meetings, and events” outlining our new approach to staff travel, meetings, and events with the goal of not going back to ‘normal’ after the pandemic. We took into account three key areas: The environment and climate change Inclusion Work/life balance We are aware that many of our members are also interested in minimizing their impacts on the environment, and we are overdue for an update on meeting our own commitments, so here goes our summary for the year 2023!

...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: Martyn Rittman   |   Last updated 2022-December-01