Public (unauthenticated) API usage policy

182 views
Skip to first unread message

Twan Driessen

unread,
Apr 11, 2025, 9:36:49 AMApr 11
to ORCID API Users
Hi all!

We at Unc Inc are developing the new website for NIOZ; the Royal Netherlands Institute for Sea Research. If you're interested, you can find their current website here: https://www.nioz.nl/en

Now, NIOZ has several hundred staff members. Quite a large number of their employees have ORCID records.
We've been asked to for each staff member with an ORCID ID, get their works, so we can show those on the website, under someone's profile, or on a project page.

We've found in your GitHub documentation a public endpoint we can call for this information.

Our plan was as follows:
1. For each known ORCID ID in their database, call: https://pub.orcid.org/v3.0/0000-0002-0103-4275/works

2. For each work in that response, get the details for that work, like so: https://pub.orcid.org/v3.0/0000-0002-0103-4275/work/182005132

3. Store that information.

Now, we know that since there's multiple people who've worked on the same publication, we will be very probably be calling the same 'work' but simply through different routes, for each ORCID ID associated with that work, at NIOZ.

Our plan was, to check the `last-modified-date` key when getting an overview of an ORCID ID's list of works from the /works endpoint.
But, I noticed that the `last-modified-date` on the sáme work, can be different, depending on whether you call that work through ORCID ID A, or B, or C.
Example:

https://pub.orcid.org/v3.0/0000-0002-0103-4275/work/182005132
https://pub.orcid.org/v3.0/0000-0002-2319-056X/work/182008916
https://pub.orcid.org/v3.0/0000-0002-4023-5600/work/182009806

All return the same details, aside from `created` `putcode` `last-modified-date` and the `path` (obviously).

So, it looks like we have no way to check if we need or don't need to make that éxtra call for the work details...

We don't want to violate usage policies for this API so I wanted to check with you what the current rate limits are and/or if we can do something clever to limit the number of calls, while still making sure we update the records on our end, when they need updating.

Thanks a lot in advance!

Twan
Software Developer at Unc Inc


Stuart A. Yeates

unread,
Apr 11, 2025, 3:41:03 PMApr 11
to Twan Driessen, ORCID API Users
Seems like a classic case where you should just be downloading the annual dump and not querying for each individual. https://info.orcid.org/documentation/integration-guide/working-with-bulk-data/  

cheers
stuart

--
...let us be heard from red core to black sky


--
You received this message because you are subscribed to the Google Groups "ORCID API Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orcid-api-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/orcid-api-users/c29aa834-6380-4255-ba33-b0857469aa92n%40googlegroups.com.

Laura Paglione

unread,
Apr 11, 2025, 7:13:47 PMApr 11
to Stuart A. Yeates, Twan Driessen, ORCID API Users
If you want to avoid calling information about the same work multiple times, you probably want to be comparing the unique identifiers for the works themselves - external-id - rather than the modified date (or perhaps even a combination of the work name & publication date if you really want to use a date). Those things are specific to the work rather than the ORCID record, so they are more likely to be the same across different records. (and they are included in the /works api call)

That said, of course, different sources for the works could have slightly different information for the same work, so you'll have to decide your preferences in that respect.  Another option for getting the details for the work is to use an authoritative source for the work information once you have the work unique identifier.

Best, L


Be different.

Laura Paglione

LauraPaglione.com

lpag...@SphericalCowGroup.com



Aaron Matherne

unread,
Apr 11, 2025, 9:41:42 PMApr 11
to Laura Paglione, Stuart A. Yeates, Twan Driessen, ORCID API Users

Kaveh Bazargan

unread,
Apr 12, 2025, 4:37:17 AMApr 12
to Aaron Matherne, Laura Paglione, Stuart A. Yeates, Twan Driessen, ORCID API Users
So why comment?



--
Kaveh Bazargan PhD
Director
Accelerating the Communication of Research
  https://rivervalley.io/gigabyte-wins-the-alpsp-scholarly-publishing-innovation-award-using-river-valleys-publishing-technology/

Twan Driessen

unread,
Apr 14, 2025, 10:14:51 AMApr 14
to ORCID API Users
Thanks for the replies all!

Stuart, that's a good suggestion. We'll keep that in mind, because it would mean it takes a year at max, before a publication could be synced.

Laura, thanks for the suggestion!
What do you mean by different sources? The only source we're using here is ORCID, so surely the work should be the same regardless of through which author we get the details?
You did give me an idea actually! When getting the details for a work, we can mark it as checked for that run, so that we don't check it again the same run :)

Cheers

Laura Paglione

unread,
Apr 14, 2025, 11:24:29 AMApr 14
to Twan Driessen, ORCID API Users
ORCID receives the details about the works from various sources, for example, the publisher, Crossref, or even the author themselves. You can see an example of that in the work you've referenced: https://pub.orcid.org/v3.0/0000-0002-0103-4275/work/182005132


<common:source>
<common:source-client-id>
<common:path>0000-0001-9884-1913</common:path>
<common:host>orcid.org</common:host>
</common:source-client-id>
<common:source-name>Crossref</common:source-name>
</common:source>
<work:title>
<common:title>Are willows suitable for flood defense? Quantifying mechanical properties of willow species</common:title>
</work:title>
<work:journal-title>Estuarine, Coastal and Shelf Science</work:journal-title>
<work:type>journal-article</work:type>
<common:publication-date>
<common:year>2025</common:year>
<common:month>04</common:month>
</common:publication-date>
<common:external-ids>
<common:external-id>
<common:external-id-type>doi</common:external-id-type>
<common:external-id-value>10.1016/j.ecss.2025.109306</common:external-id-value>
<common:external-id-normalized transient="true">10.1016/j.ecss.2025.109306</common:external-id-normalized>
<common:external-id-url>https://doi.org/10.1016/j.ecss.2025.109306</common:external-id-url>
<common:external-id-relationship>self</common:external-id-relationship>
</common:external-id>
</common:external-ids>

The XML element <common:source> indiates where the information about this work came from - in this case it is Crossref (which you can see as the source-name). 


However, the information about a work may have been added to ORCID in any number of ways. In fact, the same work may even be on a person's ORCID record more than once with different sources. Here is an example from my own record. These two works exist on my record:

When you look at them you can tell that they are for the same work, "Academic Interfederation into the 2030s" (<common:title>) - the way that you can be sure that they are the same work is because the work's unique identifier is the same for each: 
<common:external-id-type>doi</common:external-id-type>
<common:external-id-value>10.5281/zenodo.6584586</common:external-id-value>

But, if you look closely at the two works, they have different information, primarily because they came from different courses. The first one was self-reported by me (<common:source-name>Laura A D Paglione</common:source-name>) while the second one came from DataCite (<common:source-name>DataCite</common:source-name>).

What's more, the second source helpfully includes the ORCID iDs of that paper's co-authors. However, none (few?) of these co-authors have this work on their own record (full disclosure - this paper was written primarily by non-academics who likely are not using ORCID for a comprehensive listing of their works - you may not find this situation for your use case.)

When including information about a work for your use case, you may want to consider the source of that information (i.e., how it arrived in the ORCID Record). Some information will be more complete than others, so when you have a choice about which information to use, the work's source information may be helpful for you to review as well.

This set of articles may be useful as you explore how to best use the works information in ORCID records for your use case: https://support.orcid.org/hc/en-us/sections/360001495353-Works-and-peer-review

Best, L


Be different.

Laura Paglione

LauraPaglione.com

lpag...@SphericalCowGroup.com


Twan Driessen

unread,
Apr 15, 2025, 9:22:01 AMApr 15
to ORCID API Users
Hey Laura,

Thanks a lot for your elaborate response. This is really valuable!
We should definitely do checks to see if we get different details on works then and only áfter we've verified we have all teh details, mark a publication on our and as 'complete'.


If you or anyone else knows anything about ratelimits for the public API, I would very much like to know if there are any.
In any case we'll make sure not to bother with unnecessary requests.

Thanks again!

Twan

Laura Paglione

unread,
Apr 15, 2025, 11:36:58 AMApr 15
to Twan Driessen, ORCID API Users
Hi -- you can find the rate limits on the public API on this page: https://info.orcid.org/documentation/integration-guide/registering-a-public-api-client/


Be different.

Laura Paglione

LauraPaglione.com

lpag...@SphericalCowGroup.com


Twan Driessen

unread,
Apr 15, 2025, 11:38:57 AMApr 15
to ORCID API Users
Ah I totally missed that. Thanks a lot!
Reply all
Reply to author
Forward
0 new messages