REST API for POCI, the OpenCitations Index of PubMed open PMID-to-PMID references

Version: Version 1.1.0 (2023-11-06)
API URL: https://opencitations.net/index/poci/api/v1
Contact: contact@opencitations.net
License: This document is licensed with a Creative Commons Attribution 4.0 International License, while the REST API itself has been created using RAMOSE, the Restful API Manager Over SPARQL Endpoints created by Silvio Peroni, which is licensed with an ISC license.

Description back to top

This document describe the REST API for accessing the data stored in POCI hosted by OpenCitations. This API implements operations to retrieve the citation data for all the references to other works appearing in a particular bibliographic entity, or the citation data for all the references appearing in other works to a particular bibliographic entity, given the PMID of a bibliographic entity, or to retrieve citation data about a particular citation identified by means of its Open Citation Identifier (OCI).

All the present operations return either a JSON document (default) or a CSV document according to the mimetype specified in the Accept header of the request. If you would like to suggest an additional operation to be included in this API, please use the issue tracker of the OpenCitations APIs available on GitHub.

If you are going to use the REST APIs within an application/code, we encourage you to get the OpenCitations Access Token and specify it in the "authorization" header of your REST API call. Here is a usage example in Python:

from requests import get

API_CALL = "https://opencitations.net/index/poci/api/v1/references/12680890"
HTTP_HEADERS = {"authorization": "YOUR-OPENCITATIONS-ACCESS-TOKEN"}

get(API_CALL, headers=HTTP_HEADERS)

Note: we use certain legacy APIs for historical and compatibility reasons. While we encourage the use of our latest and more efficient V2 APIs, we understand that some applications may still rely on these older endpoints. Please note that legacy APIs may not receive updates or support, and their use may be phased out in the future. We recommend transitioning to our current V2 APIs for improved performance, security, and reliability.

Parameters back to top

Parameters can be used to filter and control the results returned by the API. They are passed as normal HTTP parameters in the URL of the call. They are:

1. require=<field_name>: all the rows that have an empty value in the <field_name> specified are removed from the result set - e.g. require=given_name removes all the rows that do not have any string specified in the given_name field.

2. filter=<field_name>:<operator><value>: only the rows compliant with <value> are kept in the result set. The parameter <operation> is not mandatory. If <operation> is not specified, <value> is interpreted as a regular expression, otherwise it is compared by means of the specified operation. Possible operators are "=", "<", and ">". For instance, filter=title:semantics? returns all the rows that contain the string "semantic" or "semantics" in the field title, while filter=date:>2016-05 returns all the rows that have a date greater than May 2016.

3. sort=<order>(<field_name>): sort in ascending (<order> set to "asc") or descending (<order> set to "desc") order the rows in the result set according to the values in <field_name>. For instance, sort=desc(date) sorts all the rows according to the value specified in the field date in descending order.

4. format=<format_type>: the final table is returned in the format specified in <format_type> that can be either "csv" or "json" - e.g. format=csv returns the final table in CSV format. This parameter has higher priority of the type specified through the "Accept" header of the request. Thus, if the header of a request to the API specifies Accept: text/csv and the URL of such request includes format=json, the final table is returned in JSON.

5. json=<operation_type>("<separator>",<field>,<new_field_1>,<new_field_2>,...): in case a JSON format is requested in return, tranform each row of the final JSON table according to the rule specified. If <operation_type> is set to "array", the string value associated to the field name <field> is converted into an array by splitting the various textual parts by means of <separator>. For instance, considering the JSON table [ { "names": "Doe, John; Doe, Jane" }, ... ], the execution of array("; ",names) returns [ { "names": [ "Doe, John", "Doe, Jane" ], ... ]. Instead, if <operation_type> is set to "dict", the string value associated to the field name <field> is converted into a dictionary by splitting the various textual parts by means of <separator> and by associating the new fields <new_field_1>, <new_field_2>, etc., to these new parts. For instance, considering the JSON table [ { "name": "Doe, John" }, ... ], the execution of dict(", ",name,fname,gname) returns [ { "name": { "fname": "Doe", "gname": "John" }, ... ].

It is possible to specify one or more filtering operation of the same kind (e.g. require=given_name&require=family_name). In addition, these filtering operations are applied in the order presented above - first all the require operation, then all the filter operations followed by all the sort operation, and finally the format and the json operation (if applicable). It is worth mentioning that each of the aforementioned rules is applied in order, and it works on the structure returned after the execution of the previous rule.

Example: <api_operation_url>?require=doi&filter=date:>2015&sort=desc(date).