# CORE

> Search and read CORE, the world's largest aggregator of open-access research: over 300 million papers harvested from repositories, preprint servers and journals. Find works and the repositories holding them, follow a DOI to a free copy, pull PDFs and parsed full text, count a field's output by year or author, and find the researchers working on a topic.

App · Research & Academia · 26 actions. Web page: https://docs.lodol.com/docs/integrations/core

## Actions

### Count data providers by field

Count the repositories CORE harvests, grouped by the software they run or by identifier. The software breakdown is the open-access repository landscape in one call: how many run DSpace against EPrints against OJS, narrowed to one country.

**Inputs**

- Break down by (`aggregations`, text, required): Which fields to count by. Repository software is the one worth asking for; the two ID fields count records per identifier. One or more of: `software` (Repository software (DSpace, EPrints, OJS…)), `id` (CORE data provider ID), `openDoarId` (OpenDOAR ID).
- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Name contains (`name`, text): Only return data providers whose name contains this. Matched against the repository's own name.
- Country (`country_code`, text): Only return data providers in this country, as a two-letter ISO code: gb, us, se, de.
- Type (`provider_type`, text): Only return repositories, or only journals. Leave empty for both. One of: `REPOSITORY` (Repository (institutional, subject or preprint)), `JOURNAL`.
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.

**Outputs**

- `aggregation_fields` (list)
- `aggregations` (object)
- `query` (text)
- `total_results` (number)

**Example output**

```json
{
  "aggregation_fields": [
    "software"
  ],
  "aggregations": {
    "software": {
      "dspace": 96,
      "eprints": 118,
      "ojs": 41
    }
  },
  "query": "location.countryCode:gb",
  "total_results": 284
}
```

### Count journals by subject

Count the journals matching a search, grouped by subject: the subject map of a field's publishing landscape. Subject is the one field CORE aggregates journals by, so it is also the default.

**Inputs**

- Break down by (`aggregations`, text): Which fields to count by. Subject is the only one CORE supports here, and is used when this is left empty. One or more of: `subjects` (Subject).
- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Title contains (`title`, text): Only return journals whose title contains this.
- Publisher (`publisher`, text): Only return journals from this publisher, as the journal record spells it; these names come from DOAJ and from the repositories supplying the journals, so they are not normalised the way a work's publisher is.
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.

**Outputs**

- `aggregation_fields` (list)
- `aggregations` (object)
- `query` (text)
- `total_results` (number)

**Example output**

```json
{
  "aggregation_fields": [
    "subjects"
  ],
  "aggregations": {
    "subjects": {
      "Environmental sciences": 10,
      "Science": 7,
      "climate change": 14
    }
  },
  "query": "(climate change)",
  "total_results": 96
}
```

### Count outputs by field

Break a set of harvested outputs down into counts: by subject, by contributor, by the date they were deposited or accepted, by language. Deposit dates are the interesting ones here: they say when repositories actually took material in, which publication dates do not.

**Inputs**

- Break down by (`aggregations`, text, required): Which fields to count by. Pick more than one to get several breakdowns of the same result set in one call. One or more of: `acceptedDate` (Date accepted for publication), `authors` (Author), `contributors` (Contributor (editor, translator, organisation)), `depositedDate` (Date deposited in the repository), `documentType` (Document type), `language`, `publishedDate` (Publication date), `subjects` (Subject).
- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Title contains (`title`, text): Only return records whose title contains this phrase. Matched as written, so it is the field to use when you know the paper.
- Authors (`authors`, list): Only return records by these authors. Every name given must appear, so adding a second name narrows rather than widens; use it to pin down a common surname by a co-author.
- Document types (`document_types`, text): Only return records of these types. Leave empty for every type. A record matching any one of the chosen types is included. One or more of: `research`, `research article`, `review`, `review article`, `journal article`, `conference paper`, `conference object`, `conference proceedings`, `conference poster`, `preprint`, and 25 more.
- Subjects (`subjects`, list): Only return outputs tagged with these subjects. A record matching any one of them is included. Subjects come from the repository, so they range from 'Article' and 'PeerReviewed' to real topics.
- Published from year (`year_from`, number): Only return records published in or after this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Published up to year (`year_to`, number): Only return records published in or before this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Full text only (`full_text_only`, true/false): Only return records whose full text CORE has parsed. Turn this on when the workflow goes on to read the paper rather than just cite it. Note that CORE serves the full text itself only to connections with an API key.
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.

**Outputs**

- `aggregation_fields` (list)
- `aggregations` (object)
- `query` (text)
- `total_results` (number)

**Example output**

```json
{
  "aggregation_fields": [
    "subjects",
    "language"
  ],
  "aggregations": {
    "language": {
      "en": 41022,
      "es": 1180
    },
    "subjects": {
      "Article": 8821,
      "PeerReviewed": 7415
    }
  },
  "query": "(machine learning)",
  "total_results": 52107
}
```

### Count works by field

Break a set of works down into counts instead of listing them: how much was published per year on a topic, which authors publish most on it, which repositories hold it, what document types it comes in. One call answers a question that would otherwise take thousands of paged results.

**Inputs**

- Break down by (`aggregations`, text, required): Which fields to count by. Pick more than one to get several breakdowns of the same result set in one call. One or more of: `yearPublished` (Year published), `authors` (Author), `dataProvider` (Data provider (repository or journal)), `documentType` (Document type), `publishedDate` (Publication date), `updatedDate` (Date last updated in CORE), `language`, `publisher`, `fieldOfStudy` (Field of study).
- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Title contains (`title`, text): Only return records whose title contains this phrase. Matched as written, so it is the field to use when you know the paper.
- Authors (`authors`, list): Only return records by these authors. Every name given must appear, so adding a second name narrows rather than widens; use it to pin down a common surname by a co-author.
- Document types (`document_types`, text): Only return records of these types. Leave empty for every type. A record matching any one of the chosen types is included. One or more of: `research`, `research article`, `review`, `review article`, `journal article`, `conference paper`, `conference object`, `conference proceedings`, `conference poster`, `preprint`, and 25 more.
- Data providers (`data_provider_ids`, list): Only return works held by these data providers, by CORE ID. A work matching any one of them is included. 'Search data providers' returns the ID on every record.
- Published from year (`year_from`, number): Only return records published in or after this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Published up to year (`year_to`, number): Only return records published in or before this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Full text only (`full_text_only`, true/false): Only return records whose full text CORE has parsed. Turn this on when the workflow goes on to read the paper rather than just cite it. Note that CORE serves the full text itself only to connections with an API key.
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.

**Outputs**

- `aggregation_fields` (list)
- `aggregations` (object)
- `query` (text)
- `total_results` (number)

**Example output**

```json
{
  "aggregation_fields": [
    "yearPublished",
    "documentType"
  ],
  "aggregations": {
    "documentType": {
      "research article": 306314,
      "thesis": 356641
    },
    "yearPublished": {
      "2022": 151742,
      "2023": 151061,
      "2024": 108312
    }
  },
  "query": "(climate change)",
  "total_results": 1284310
}
```

### Download a work's PDF

Download a work's PDF from CORE and keep it as a document a later step can read, attach or send on. Reach for the record's own 'downloadUrl' first: it points at the repository holding the paper, and CORE asks that its own download route be used only when that one is unreachable. This route needs an API key and costs more of your daily allowance than a search does. CORE's work-level download is prone to timing out at its end; when it does, this falls back to downloading through the work's own harvested copies, and 'served_by' says which route answered.

**Inputs**

- Work (`work_id`, text, required): The work to look up: its numeric CORE ID, a DOI, a core.ac.uk link, or a prefixed identifier such as 'oai:oro.open.ac.uk:12345'. 'Search works' returns the ID on every record. A DOI is resolved by searching for it first, which costs one extra request against your daily allowance; chain the ID from an earlier step where you can.

**Outputs**

- `byte_size` (number)
- `content_type` (text)
- `document_ref` (text)
- `documents` (list)
- `filename` (text)
- `identifier` (text)
- `served_by` (text)
- `source_url` (text)
- `url` (text)

**Example output**

```json
{
  "byte_size": 418233,
  "content_type": "application/pdf",
  "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
  "documents": [
    {
      "content_type": "application/pdf",
      "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
      "filename": "core-work-267312.pdf",
      "size_bytes": 418233,
      "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
    }
  ],
  "filename": "core-work-267312.pdf",
  "identifier": "267312",
  "source_url": "https://api.core.ac.uk/v3/works/267312/download",
  "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
}
```

### Download an output's PDF

Download one harvested output's PDF from CORE and keep it as a document. As with the work-level download, the record's own 'downloadUrl' is the route CORE prefers; this one needs an API key and costs more of your daily allowance.

**Inputs**

- Output (`output_id`, text, required): The output to look up, by its CORE ID. Chain it from 'Search outputs' or 'List a work's outputs', which return one on every record: an output ID is not something to type from memory. A core.ac.uk link to the output works in place of the bare ID.

**Outputs**

- `byte_size` (number)
- `content_type` (text)
- `document_ref` (text)
- `documents` (list)
- `filename` (text)
- `identifier` (text)
- `served_by` (text)
- `source_url` (text)
- `url` (text)

**Example output**

```json
{
  "byte_size": 418233,
  "content_type": "application/pdf",
  "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
  "documents": [
    {
      "content_type": "application/pdf",
      "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
      "filename": "core-output-80549003.pdf",
      "size_bytes": 418233,
      "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
    }
  ],
  "filename": "core-output-80549003.pdf",
  "identifier": "80549003",
  "source_url": "https://api.core.ac.uk/v3/outputs/80549003/download",
  "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
}
```

### Find a free copy by DOI

Given a DOI, find a link to a freely readable copy. CORE looks through its own index and then outside it, so this answers 'is there a version of this paper anyone can read' for a DOI that is otherwise behind a paywall. A DOI with no free copy comes back as 'found: false' rather than failing, so a reading-list workflow can branch on it.

**Inputs**

- DOI (`doi`, text, required): The DOI to find a free copy of. A doi.org link works as well as the bare DOI.
- Title (`title`, text): The paper's title, as extra context when the DOI alone does not resolve.
- Year (`year`, number): The publication year, as extra context. From 1000 to 2999.

**Outputs**

- `doi` (text)
- `found` (true/false)
- `full_text_link` (text)
- `source` (text)

**Example output**

```json
{
  "doi": "10.1038/s41597-023-02208-w",
  "found": true,
  "full_text_link": "https://core.ac.uk/download/558621925.pdf",
  "source": "CORE"
}
```

### Find experts on a topic

Find the researchers publishing on a topic. Describe it the same way you would for 'Find related works': a passage of text, a title and abstract, or a CORE record. CORE then answers with people rather than papers: reviewers for a submission, collaborators for a grant, the group already working on your question. This is a CORE Labs endpoint, so what each record carries is CORE's to change.

**Inputs**

- Text (`text`, text): A passage to match against: a paragraph, a research question, a grant abstract. The more you give, the better the match.
- Title (`title`, text): The title of the paper or topic to match against.
- Abstract (`abstract`, text): The abstract to match against. Sending a title and an abstract together is what gives the best matches.
- Record (`identifier`, text): A record to find experts for, instead of text. Use 'core:<id>' for a CORE record.
- Authors (`authors`, list): The authors of the paper being matched, as extra context.
- Number of results (`limit`, number): How many results to return (1–100). From 1 to 100.
- Limit to data provider (`data_provider_id`, text): Only consider records from this data provider, by CORE ID. Use it to keep the answer inside one repository's holdings.

**Outputs**

- `result_count` (number)
- `results` (list)

**Example output**

```json
{
  "result_count": 1,
  "results": [
    {
      "dataProviderId": 86,
      "name": "Petr Knoth",
      "score": 0.91,
      "works": 259
    }
  ]
}
```

### Find related works

Find research related to a paper, or to a description of one. Point it at a CORE record with 'core:<id>', at another identifier it can resolve, or at nothing but a title and an abstract, which makes it a literature search for a paper that has not been written yet. The more context you send, the better the matches.

**Inputs**

- Record (`identifier`, text): A record to find work like: 'core:' followed by a CORE work ID, or any other identifier CORE can resolve. Chain the ID from 'Search works'. Leave empty to match on text instead.
- Text (`text`, text): A passage to match against: a paragraph, a research question, a grant abstract. The more you give, the better the match.
- Title (`title`, text): The title of the paper or topic to match against.
- Abstract (`abstract`, text): The abstract to match against. Sending a title and an abstract together is what gives the best matches.
- Authors (`authors`, list): The authors of the paper being matched, as extra context.
- Number of results (`limit`, number): How many results to return (1–100). From 1 to 100.
- Limit to data provider (`data_provider_id`, text): Only consider records from this data provider, by CORE ID. Use it to keep the answer inside one repository's holdings.

**Outputs**

- `result_count` (number)
- `results` (list)

**Example output**

```json
{
  "result_count": 1,
  "results": [
    {
      "abstract": "The Open Access movement has been successful in increasing the number of freely available research papers, but the potential of text and data mining over this corpus is still largely unrealised.",
      "authors": [
        {
          "name": "Petr Knoth"
        },
        {
          "name": "Zdenek Zdrahal"
        }
      ],
      "dataProviders": [
        {
          "id": 86,
          "name": "Open Research Online",
          "url": "https://oro.open.ac.uk"
        }
      ],
      "documentType": "research article",
      "doi": "10.1045/november2012-knoth",
      "downloadUrl": "https://core.ac.uk/download/267312.pdf",
      "id": 267312,
      "language": {
        "code": "en",
        "name": "English"
      },
      "links": [
        {
          "type": "download",
          "url": "https://core.ac.uk/download/267312.pdf"
        }
      ],
      "publishedDate": "2012-11-01T00:00:00",
      "publisher": "CNRI Acct",
      "title": "CORE: three access levels to underpin open access",
      "yearPublished": 2012
    }
  ]
}
```

### Get a data provider

Fetch one repository or journal in full: its name and institution, its OAI-PMH endpoint and metadata format, the software it runs, its location, its ROR and OpenDOAR identifiers, and its aliases. Takes a CORE ID or 'opendoar:<id>'.

**Inputs**

- Data provider (`data_provider_id`, text, required): The repository or journal to look up: its numeric CORE ID, or 'opendoar:<id>' to use its OpenDOAR ID instead. 'Search data providers' returns the CORE ID on every record.

**Outputs**

- `data_provider` (object)
- `data_provider_id` (text)

**Example output**

```json
{
  "data_provider": {
    "aliases": [
      "cy: Y Brifysgol Agored",
      "OU"
    ],
    "createdDate": "2011-05-06T10:11:21+00:00",
    "email": "library-research-support@open.ac.uk",
    "homepageUrl": "https://oro.open.ac.uk",
    "id": 86,
    "institutionName": "The Open University",
    "location": {
      "countryCode": "gb",
      "latitude": 52.0333,
      "longitude": -0.7
    },
    "metadataFormat": "rioxx",
    "name": "Open Research Online",
    "oaiPmhUrl": "https://oro.open.ac.uk/cgi/oai2",
    "openDoarId": 300,
    "rorId": "https://ror.org/05mzfcs16",
    "software": "eprints",
    "type": "REPOSITORY"
  },
  "data_provider_id": "86"
}
```

### Get a data provider's statistics

How much content a repository has contributed: metadata records, and how many of those CORE holds full text for. Leave the extras off for the headline counts, which is the cheaper call. Turn any of them on and CORE returns the fuller picture instead: the deposit history over time, the per-source breakdown, or one OAI set.

**Inputs**

- Data provider (`data_provider_id`, text, required): The repository or journal to look up: its numeric CORE ID, or 'opendoar:<id>' to use its OpenDOAR ID instead. 'Search data providers' returns the CORE ID on every record.
- Include deposit history (`include_deposit_history`, true/false): Return the repository's deposit counts over time as well as its totals: the series behind 'is this repository still growing'.
- Include per-source breakdown (`include_raw_stats`, true/false): Return the statistics CORE holds per underlying source, and when each was last seen.
- OAI set (`oai_set`, text): Limit the statistics to one OAI-PMH set: a repository's own grouping, such as a faculty or a collection.
- Recalculate now (`refresh`, true/false): Ask CORE to recalculate rather than serve what it last computed. Slower, and only worth it right after a harvest.

**Outputs**

- `data_provider_id` (text)
- `detailed` (true/false)
- `stats` (object)

**Example output**

```json
{
  "data_provider_id": "86",
  "detailed": false,
  "stats": {
    "countFulltext": 16795,
    "countMetadata": 47000,
    "history": null,
    "id": 86
  }
}
```

### Get a journal

Fetch one journal by ISSN or by its CORE identifier: its title, publisher, language, subject list, every identifier CORE holds for it, and the data provider supplying it.

**Inputs**

- Journal (`journal_id`, text, required): The journal to look up, by ISSN or by its CORE identifier. An ISSN works with or without its hyphen. CORE identifiers are prefixed, for example 'oai:doaj.org/journal:<id>'.

**Outputs**

- `journal` (object)
- `journal_id` (text)

**Example output**

```json
{
  "journal": {
    "dataProviderId": "645",
    "identifiers": [
      "oai:doaj.org/journal:fc6f85dc44ed458b983814eb3628da53",
      "issn:1179-1497",
      "url:http://doaj.org/toc/fc6f85dc44ed458b983814eb3628da53"
    ],
    "language": "English",
    "publisher": "Dove Medical Press",
    "subjects": [
      "neuropsychiatry",
      "HIV research",
      "LCC:Medicine"
    ],
    "title": "Neurobehavioral HIV Medicine"
  },
  "journal_id": "issn:1179-1497"
}
```

### Get a journal's statistics

How much of a journal CORE holds: metadata records, records with full text, and how many carry a DOI. The counts come from the data provider supplying the journal, so they match that provider's own statistics.

**Inputs**

- Journal (`journal_id`, text, required): The journal to look up, by ISSN or by its CORE identifier. An ISSN works with or without its hyphen. CORE identifiers are prefixed, for example 'oai:doaj.org/journal:<id>'.

**Outputs**

- `journal_id` (text)
- `stats` (object)

**Example output**

```json
{
  "journal_id": "issn:1179-1497",
  "stats": {
    "count_fulltext": "1188",
    "count_metadata": "1204",
    "doi_count": "1201",
    "identifier": 645
  }
}
```

### Get a work

Fetch one research work in full: title, abstract, authors, identifiers, journal, publisher, links and, on a connection with an API key, the parsed full text. Takes a CORE ID, a DOI or a core.ac.uk link.

**Inputs**

- Work (`work_id`, text, required): The work to look up: its numeric CORE ID, a DOI, a core.ac.uk link, or a prefixed identifier such as 'oai:oro.open.ac.uk:12345'. 'Search works' returns the ID on every record. A DOI is resolved by searching for it first, which costs one extra request against your daily allowance; chain the ID from an earlier step where you can.

**Outputs**

- `work` (object)
- `work_id` (text)

**Example output**

```json
{
  "work": {
    "abstract": "The Open Access movement has been successful in increasing the number of freely available research papers, but the potential of text and data mining over this corpus is still largely unrealised.",
    "authors": [
      {
        "name": "Petr Knoth"
      },
      {
        "name": "Zdenek Zdrahal"
      }
    ],
    "dataProviders": [
      {
        "id": 86,
        "name": "Open Research Online",
        "url": "https://oro.open.ac.uk"
      }
    ],
    "documentType": "research article",
    "doi": "10.1045/november2012-knoth",
    "downloadUrl": "https://core.ac.uk/download/267312.pdf",
    "id": 267312,
    "language": {
      "code": "en",
      "name": "English"
    },
    "links": [
      {
        "type": "download",
        "url": "https://core.ac.uk/download/267312.pdf"
      }
    ],
    "publishedDate": "2012-11-01T00:00:00",
    "publisher": "CNRI Acct",
    "title": "CORE: three access levels to underpin open access",
    "yearPublished": 2012
  },
  "work_id": "267312"
}
```

### Get a work's dates

Fetch the lifecycle dates CORE holds for a work: when it was deposited, accepted, published and last updated. Useful for measuring how long a repository takes to make accepted work available.

**Inputs**

- Work (`work_id`, text, required): The work to look up: its numeric CORE ID, a DOI, a core.ac.uk link, or a prefixed identifier such as 'oai:oro.open.ac.uk:12345'. 'Search works' returns the ID on every record. A DOI is resolved by searching for it first, which costs one extra request against your daily allowance; chain the ID from an earlier step where you can.

**Outputs**

- `stats` (object)
- `work_id` (text)

**Example output**

```json
{
  "stats": {
    "accepted_date": "2012-10-18T00:00:00Z",
    "deposited_date": "2012-12-04T00:00:00Z",
    "id": 267312,
    "published_date": "2012-11-01T00:00:00Z",
    "updated_date": "2024-08-16T00:03:23Z"
  },
  "work_id": "267312"
}
```

### Get a work's parsed structure (TEI)

Download the TEI XML CORE produced from a work's PDF, and keep it as a document. TEI is the paper taken apart: sections and headings, figures and tables, and a reference list with each citation split into author, title, year and DOI. It is what to fetch when a workflow needs to read a paper's structure rather than show its pages.

**Inputs**

- Work (`work_id`, text, required): The work to look up: its numeric CORE ID, a DOI, a core.ac.uk link, or a prefixed identifier such as 'oai:oro.open.ac.uk:12345'. 'Search works' returns the ID on every record. A DOI is resolved by searching for it first, which costs one extra request against your daily allowance; chain the ID from an earlier step where you can.

**Outputs**

- `byte_size` (number)
- `content_type` (text)
- `document_ref` (text)
- `documents` (list)
- `filename` (text)
- `identifier` (text)
- `served_by` (text)
- `source_url` (text)
- `url` (text)

**Example output**

```json
{
  "byte_size": 96412,
  "content_type": "application/xml",
  "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
  "documents": [
    {
      "content_type": "application/xml",
      "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
      "filename": "core-work-127610059.tei.xml",
      "size_bytes": 96412,
      "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
    }
  ],
  "filename": "core-work-127610059.tei.xml",
  "identifier": "127610059",
  "source_url": "https://api.core.ac.uk/v3/works/tei/127610059",
  "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
}
```

### Get an output

Fetch one harvested output in full: one repository's copy of a paper, with the metadata that repository supplied: its OAI identifier, its licence, its set memberships, its download links and its Sustainable Development Goal labels.

**Inputs**

- Output (`output_id`, text, required): The output to look up, by its CORE ID. Chain it from 'Search outputs' or 'List a work's outputs', which return one on every record: an output ID is not something to type from memory. A core.ac.uk link to the output works in place of the bare ID.

**Outputs**

- `output` (object)
- `output_id` (text)

**Example output**

```json
{
  "output": {
    "authors": [
      "Knoth, Petr",
      "Zdrahal, Zdenek"
    ],
    "documentType": [
      "research article"
    ],
    "doi": "10.1045/november2012-knoth",
    "downloadUrl": "https://core.ac.uk/download/80549003.pdf",
    "fulltextStatus": "enabled",
    "id": 80549003,
    "license": "http://creativecommons.org/licenses/by/3.0/",
    "oai": "oai:oro.open.ac.uk:35755",
    "repositories": {
      "id": "86",
      "name": "Open Research Online"
    },
    "title": "CORE: three access levels to underpin open access",
    "yearPublished": "2012"
  },
  "output_id": "80549003"
}
```

### Get an output's dates

Fetch the dates CORE holds for one harvested output: deposited, published, accepted, created and last updated.

**Inputs**

- Output (`output_id`, text, required): The output to look up, by its CORE ID. Chain it from 'Search outputs' or 'List a work's outputs', which return one on every record: an output ID is not something to type from memory. A core.ac.uk link to the output works in place of the bare ID.

**Outputs**

- `output_id` (text)
- `stats` (object)

**Example output**

```json
{
  "output_id": "80549003",
  "stats": {
    "accepted_date": "2012-10-18T00:00:00Z",
    "created_date": "2013-01-09T11:20:44Z",
    "deposited_date": "2012-12-04T00:00:00Z",
    "id": 80549003,
    "published_date": "2012-11-01T00:00:00Z",
    "updated_date": "2024-08-16T00:03:23Z"
  }
}
```

### Get an output's harvest history

Fetch every version of an output's metadata CORE has harvested, oldest first. One entry per harvest since CORE first saw the record, so a workflow can see when a repository corrected a title, added a DOI or changed a licence, and when nothing has changed in years.

**Inputs**

- Output (`output_id`, text, required): The output to look up, by its CORE ID. Chain it from 'Search outputs' or 'List a work's outputs', which return one on every record: an output ID is not something to type from memory. A core.ac.uk link to the output works in place of the bare ID.

**Outputs**

- `output_id` (text)
- `version_count` (number)
- `versions` (list)

**Example output**

```json
{
  "output_id": "80549003",
  "version_count": 1,
  "versions": [
    {
      "data": {
        "title": "CORE: three access levels"
      },
      "xml": "<record>\u2026</record>"
    }
  ]
}
```

### Get an output's raw XML record

Download the raw XML metadata record for an output and keep it as a document. This is exactly what the repository's OAI-PMH endpoint served, before CORE normalised anything: the record to reach for when a field looks wrong and the question is whether CORE or the repository put it there.

**Inputs**

- Output (`output_id`, text, required): The output to look up, by its CORE ID. Chain it from 'Search outputs' or 'List a work's outputs', which return one on every record: an output ID is not something to type from memory. A core.ac.uk link to the output works in place of the bare ID.

**Outputs**

- `byte_size` (number)
- `content_type` (text)
- `document_ref` (text)
- `documents` (list)
- `filename` (text)
- `identifier` (text)
- `served_by` (text)
- `source_url` (text)
- `url` (text)

**Example output**

```json
{
  "byte_size": 4182,
  "content_type": "application/xml",
  "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
  "documents": [
    {
      "content_type": "application/xml",
      "document_ref": "doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e",
      "filename": "core-output-80549003.xml",
      "size_bytes": 4182,
      "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
    }
  ],
  "filename": "core-output-80549003.xml",
  "identifier": "80549003",
  "source_url": "https://api.core.ac.uk/v3/outputs/80549003/raw",
  "url": "/actions/core/serve-document/doc_9c1a2f7d3a5e6b40b1f0c8a29f1d4b0e"
}
```

### List a work's outputs

List every harvested copy behind one work: the same paper as each repository holds it. Use it to find which repositories have a version, to compare their metadata, or to pick a copy with a licence that allows what you want to do next.

**Inputs**

- Work (`work_id`, text, required): The work to look up: its numeric CORE ID, a DOI, a core.ac.uk link, or a prefixed identifier such as 'oai:oro.open.ac.uk:12345'. 'Search works' returns the ID on every record. A DOI is resolved by searching for it first, which costs one extra request against your daily allowance; chain the ID from an earlier step where you can.
- Number of results (`limit`, number): How many outputs to return (1–100). Defaults to 10. From 1 to 100.
- Skip (`offset`, number): How many results to skip, for paging. Use the 'next_offset' from a previous run to fetch the following page. CORE's search reaches 10,000 records in total, so narrow the query rather than paging past that. From 0 to 10000.

**Outputs**

- `has_more` (true/false)
- `limit` (number)
- `next_offset` (number)
- `offset` (number)
- `query` (text)
- `result_count` (number)
- `results` (list)
- `search_id` (text)
- `total_results` (number)
- `work_id` (text)

**Example output**

```json
{
  "has_more": true,
  "limit": 10,
  "next_offset": 1,
  "offset": 0,
  "query": "",
  "result_count": 1,
  "results": [
    {
      "authors": [
        "Knoth, Petr",
        "Zdrahal, Zdenek"
      ],
      "documentType": [
        "research article"
      ],
      "doi": "10.1045/november2012-knoth",
      "downloadUrl": "https://core.ac.uk/download/80549003.pdf",
      "fulltextStatus": "enabled",
      "id": 80549003,
      "license": "http://creativecommons.org/licenses/by/3.0/",
      "oai": "oai:oro.open.ac.uk:35755",
      "repositories": {
        "id": "86",
        "name": "Open Research Online"
      },
      "title": "CORE: three access levels to underpin open access",
      "yearPublished": "2012"
    }
  ],
  "search_id": "b1f0c8a2-9f1d-4b0e-9c1a-2f7d3a5e6b40",
  "total_results": 3,
  "work_id": "267312"
}
```

### Search a data provider's outputs

Search inside one repository's holdings, or list them all by leaving the query empty. This is the only CORE search that takes a sort order, so it is the way to ask a repository what it has added most recently.

**Inputs**

- Data provider (`data_provider_id`, text, required): The repository or journal to look up: its numeric CORE ID, or 'opendoar:<id>' to use its OpenDOAR ID instead. 'Search data providers' returns the CORE ID on every record.
- Search terms (`query`, text): Words to search for inside this repository's records. Leave empty to list everything it holds.
- Sort by (`sort`, text): How to order the results. Relevance is the default; newest first is what a 'what's new in this repository' workflow wants. One of: `relevance` (Relevance to the query), `recency` (Newest first).
- Number of results (`limit`, number): How many outputs to return (1–100). Defaults to 10. From 1 to 100.
- Skip (`offset`, number): How many results to skip, for paging. Use the 'next_offset' from a previous run to fetch the following page. CORE's search reaches 10,000 records in total, so narrow the query rather than paging past that. From 0 to 10000.

**Outputs**

- `data_provider_id` (text)
- `has_more` (true/false)
- `limit` (number)
- `next_offset` (number)
- `offset` (number)
- `query` (text)
- `result_count` (number)
- `results` (list)
- `search_id` (text)
- `total_results` (number)

**Example output**

```json
{
  "data_provider_id": "86",
  "has_more": true,
  "limit": 10,
  "next_offset": 1,
  "offset": 0,
  "query": "climate",
  "result_count": 1,
  "results": [
    {
      "authors": [
        "Knoth, Petr",
        "Zdrahal, Zdenek"
      ],
      "documentType": [
        "research article"
      ],
      "doi": "10.1045/november2012-knoth",
      "downloadUrl": "https://core.ac.uk/download/80549003.pdf",
      "fulltextStatus": "enabled",
      "id": 80549003,
      "license": "http://creativecommons.org/licenses/by/3.0/",
      "oai": "oai:oro.open.ac.uk:35755",
      "repositories": {
        "id": "86",
        "name": "Open Research Online"
      },
      "title": "CORE: three access levels to underpin open access",
      "yearPublished": "2012"
    }
  ],
  "search_id": "b1f0c8a2-9f1d-4b0e-9c1a-2f7d3a5e6b40",
  "total_results": 10733
}
```

### Search data providers

Search the repositories, preprint servers, journals and publishers CORE harvests from. Filter by country, by the software the repository runs, by metadata format, or by whether it is a repository or a journal. Every record carries the CORE ID the other data-provider actions take.

**Inputs**

- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Name contains (`name`, text): Only return data providers whose name contains this. Matched against the repository's own name.
- Country (`country_code`, text): Only return data providers in this country, as a two-letter ISO code: gb, us, se, de.
- Repository software (`software`, text): Only return data providers running one of these platforms. CORE detects the software automatically. A provider matching any one of the chosen platforms is included. One or more of: `dspace`, `eprints`, `ojs` (Open Journal Systems (OJS)), `digitalcommons` (Digital Commons), `bepress`, `weko`, `dataverse`, `fedora`, `islandora`, `pure`, and 3 more.
- Type (`provider_type`, text): Only return repositories, or only journals. Leave empty for both. One of: `REPOSITORY` (Repository (institutional, subject or preprint)), `JOURNAL`.
- Metadata format (`metadata_format`, text): Only return data providers publishing this metadata format over OAI-PMH, such as rioxx or oai_dc.
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.
- Number of results (`limit`, number): How many data providers to return (1–100). Defaults to 10. From 1 to 100.
- Skip (`offset`, number): How many results to skip, for paging. Use the 'next_offset' from a previous run to fetch the following page. CORE's search reaches 10,000 records in total, so narrow the query rather than paging past that. From 0 to 10000.
- Include statistics (`include_stats`, true/false): Ask CORE for the statistics that go with these results. It makes the response noticeably slower, so leave it off unless a later step reads them.

**Outputs**

- `has_more` (true/false)
- `limit` (number)
- `next_offset` (number)
- `offset` (number)
- `query` (text)
- `result_count` (number)
- `results` (list)
- `search_id` (text)
- `total_results` (number)

**Example output**

```json
{
  "has_more": true,
  "limit": 10,
  "next_offset": 1,
  "offset": 0,
  "query": "location.countryCode:gb AND software:\"eprints\"",
  "result_count": 1,
  "results": [
    {
      "aliases": [
        "cy: Y Brifysgol Agored",
        "OU"
      ],
      "createdDate": "2011-05-06T10:11:21+00:00",
      "email": "library-research-support@open.ac.uk",
      "homepageUrl": "https://oro.open.ac.uk",
      "id": 86,
      "institutionName": "The Open University",
      "location": {
        "countryCode": "gb",
        "latitude": 52.0333,
        "longitude": -0.7
      },
      "metadataFormat": "rioxx",
      "name": "Open Research Online",
      "oaiPmhUrl": "https://oro.open.ac.uk/cgi/oai2",
      "openDoarId": 300,
      "rorId": "https://ror.org/05mzfcs16",
      "software": "eprints",
      "type": "REPOSITORY"
    }
  ],
  "search_id": "b1f0c8a2-9f1d-4b0e-9c1a-2f7d3a5e6b40",
  "total_results": 214
}
```

### Search journals

Search the journals in CORE's collection, by title, subject, ISSN or publisher. Journal records come from DOAJ members, Open Journal Systems repositories and publishers CORE aggregates directly, and each one names the data provider supplying it.

**Inputs**

- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Title contains (`title`, text): Only return journals whose title contains this.
- Subjects (`subjects`, list): Only return journals covering these subjects. A journal matching any one of them is included.
- ISSN (`issn`, text): Only return the journal with this ISSN. Works with or without the hyphen.
- Publisher (`publisher`, text): Only return journals from this publisher, as the journal record spells it; these names come from DOAJ and from the repositories supplying the journals, so they are not normalised the way a work's publisher is.
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.
- Number of results (`limit`, number): How many journals to return (1–100). Defaults to 10. From 1 to 100.
- Skip (`offset`, number): How many results to skip, for paging. Use the 'next_offset' from a previous run to fetch the following page. CORE's search reaches 10,000 records in total, so narrow the query rather than paging past that. From 0 to 10000.
- Include statistics (`include_stats`, true/false): Ask CORE for the statistics that go with these results. It makes the response noticeably slower, so leave it off unless a later step reads them.

**Outputs**

- `has_more` (true/false)
- `limit` (number)
- `next_offset` (number)
- `offset` (number)
- `query` (text)
- `result_count` (number)
- `results` (list)
- `search_id` (text)
- `total_results` (number)

**Example output**

```json
{
  "has_more": true,
  "limit": 10,
  "next_offset": 1,
  "offset": 0,
  "query": "title:\"Brain\" AND subjects:\"neuroscience\"",
  "result_count": 1,
  "results": [
    {
      "dataProviderId": "645",
      "identifiers": [
        "oai:doaj.org/journal:fc6f85dc44ed458b983814eb3628da53",
        "issn:1179-1497",
        "url:http://doaj.org/toc/fc6f85dc44ed458b983814eb3628da53"
      ],
      "language": "English",
      "publisher": "Dove Medical Press",
      "subjects": [
        "neuropsychiatry",
        "HIV research",
        "LCC:Medicine"
      ],
      "title": "Neurobehavioral HIV Medicine"
    }
  ],
  "search_id": "b1f0c8a2-9f1d-4b0e-9c1a-2f7d3a5e6b40",
  "total_results": 37
}
```

### Search outputs

Search the raw records CORE harvested, exactly as each repository supplied them: not deduplicated, not enriched. Use this rather than 'Search works' when the question is about a particular copy: which repository holds it, what licence it carries, what the repository called it. Filter by subject, licence, OAI identifier and more.

**Inputs**

- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Title contains (`title`, text): Only return records whose title contains this phrase. Matched as written, so it is the field to use when you know the paper.
- Authors (`authors`, list): Only return records by these authors. Every name given must appear, so adding a second name narrows rather than widens; use it to pin down a common surname by a co-author.
- DOI (`doi`, text): Only return records with this DOI. A doi.org link works as well as the bare DOI.
- Publisher (`publisher`, text): Only return records from this publisher. CORE normalises publisher names against Crossref's, so use the name as Crossref spells it.
- Document types (`document_types`, text): Only return records of these types. Leave empty for every type. A record matching any one of the chosen types is included. One or more of: `research`, `research article`, `review`, `review article`, `journal article`, `conference paper`, `conference object`, `conference proceedings`, `conference poster`, `preprint`, and 25 more.
- Subjects (`subjects`, list): Only return outputs tagged with these subjects. A record matching any one of them is included. Subjects come from the repository, so they range from 'Article' and 'PeerReviewed' to real topics.
- Published from year (`year_from`, number): Only return records published in or after this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Published up to year (`year_to`, number): Only return records published in or before this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Published on or after (`published_from`, date): Only return records published on or after this date. Use this rather than the year boxes when the window is narrower than a year; records with no exact publication date on file are excluded.
- Published on or before (`published_to`, date): Only return records published on or before this date. Records with no exact publication date on file are excluded.
- Full text only (`full_text_only`, true/false): Only return records whose full text CORE has parsed. Turn this on when the workflow goes on to read the paper rather than just cite it. Note that CORE serves the full text itself only to connections with an API key.
- Must have (`must_exist`, text): Only return outputs that carry all of these. A licence, for instance, is what tells you whether the copy can be redistributed. One or more of: `fullText` (Full text CORE has parsed), `doi` (A DOI), `abstract` (An abstract), `downloadUrl` (A download link), `license` (A licence), `oai` (An OAI identifier), `journals` (Journal details), `sdg` (Sustainable Development Goal labels).
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.
- Number of results (`limit`, number): How many outputs to return (1–100). Defaults to 10. From 1 to 100.
- Skip (`offset`, number): How many results to skip, for paging. Use the 'next_offset' from a previous run to fetch the following page. CORE's search reaches 10,000 records in total, so narrow the query rather than paging past that. From 0 to 10000.
- Include statistics (`include_stats`, true/false): Ask CORE for the statistics that go with these results. It makes the response noticeably slower, so leave it off unless a later step reads them.

**Outputs**

- `has_more` (true/false)
- `limit` (number)
- `next_offset` (number)
- `offset` (number)
- `query` (text)
- `result_count` (number)
- `results` (list)
- `search_id` (text)
- `total_results` (number)

**Example output**

```json
{
  "has_more": true,
  "limit": 10,
  "next_offset": 1,
  "offset": 0,
  "query": "title:\"open access\"",
  "result_count": 1,
  "results": [
    {
      "authors": [
        "Knoth, Petr",
        "Zdrahal, Zdenek"
      ],
      "documentType": [
        "research article"
      ],
      "doi": "10.1045/november2012-knoth",
      "downloadUrl": "https://core.ac.uk/download/80549003.pdf",
      "fulltextStatus": "enabled",
      "id": 80549003,
      "license": "http://creativecommons.org/licenses/by/3.0/",
      "oai": "oai:oro.open.ac.uk:35755",
      "repositories": {
        "id": "86",
        "name": "Open Research Online"
      },
      "title": "CORE: three access levels to underpin open access",
      "yearPublished": "2012"
    }
  ],
  "search_id": "b1f0c8a2-9f1d-4b0e-9c1a-2f7d3a5e6b40",
  "total_results": 48211
}
```

### Search works

Search CORE's collection of open-access research papers. A work is the paper itself: CORE deduplicates the copies it harvested from different repositories into one record, so this is the search to use for 'find me papers about X'. Filter by author, year, publication date, publisher, document type, repository, or whether CORE holds the full text. Paging reaches 10,000 records.

**Inputs**

- Search terms (`query`, text): Words to search for across every indexed field: title, abstract, authors, full text. Leave it empty and use the filters below to browse instead. CORE's own query syntax works here too: quotes for an exact phrase, AND / OR, and parentheses for grouping. Whatever you type is grouped before the filters are applied, so an OR here cannot spill into them.
- Title contains (`title`, text): Only return records whose title contains this phrase. Matched as written, so it is the field to use when you know the paper.
- Authors (`authors`, list): Only return records by these authors. Every name given must appear, so adding a second name narrows rather than widens; use it to pin down a common surname by a co-author.
- DOI (`doi`, text): Only return records with this DOI. A doi.org link works as well as the bare DOI.
- Publisher (`publisher`, text): Only return records from this publisher. CORE normalises publisher names against Crossref's, so use the name as Crossref spells it.
- Document types (`document_types`, text): Only return records of these types. Leave empty for every type. A record matching any one of the chosen types is included. One or more of: `research`, `research article`, `review`, `review article`, `journal article`, `conference paper`, `conference object`, `conference proceedings`, `conference poster`, `preprint`, and 25 more.
- Data providers (`data_provider_ids`, list): Only return works held by these data providers, by CORE ID. A work matching any one of them is included. 'Search data providers' returns the ID on every record.
- Published from year (`year_from`, number): Only return records published in or after this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Published up to year (`year_to`, number): Only return records published in or before this year. Can be used on its own for an open-ended range. From 1000 to 2999.
- Published on or after (`published_from`, date): Only return records published on or after this date. Use this rather than the year boxes when the window is narrower than a year; records with no exact publication date on file are excluded.
- Published on or before (`published_to`, date): Only return records published on or before this date. Records with no exact publication date on file are excluded.
- Full text only (`full_text_only`, true/false): Only return records whose full text CORE has parsed. Turn this on when the workflow goes on to read the paper rather than just cite it. Note that CORE serves the full text itself only to connections with an API key.
- Must have (`must_exist`, text): Only return works that carry all of these. A quick way to ask for records complete enough for what the workflow does next: a DOI to cite, an abstract to summarise, a reference list to follow. One or more of: `fullText` (Full text CORE has parsed), `doi` (A DOI), `abstract` (An abstract), `downloadUrl` (A download link), `arxivId` (An arXiv ID), `pubmedId` (A PubMed ID), `journals` (Journal details), `references` (A parsed reference list).
- Extra query (`extra_query`, text): Anything else in CORE's query language, ANDed onto the filters above: a field this form does not offer, a range, or an '_exists_:field' test. It is grouped before it joins the rest, so an OR inside it stays inside it.
- Number of results (`limit`, number): How many works to return (1–100). Defaults to 10. From 1 to 100.
- Skip (`offset`, number): How many results to skip, for paging. Use the 'next_offset' from a previous run to fetch the following page. CORE's search reaches 10,000 records in total, so narrow the query rather than paging past that. From 0 to 10000.
- Include statistics (`include_stats`, true/false): Ask CORE for the statistics that go with these results. It makes the response noticeably slower, so leave it off unless a later step reads them.

**Outputs**

- `has_more` (true/false)
- `limit` (number)
- `next_offset` (number)
- `offset` (number)
- `query` (text)
- `result_count` (number)
- `results` (list)
- `search_id` (text)
- `total_results` (number)

**Example output**

```json
{
  "has_more": true,
  "limit": 10,
  "next_offset": 1,
  "offset": 0,
  "query": "(open access) AND yearPublished>=2010",
  "result_count": 1,
  "results": [
    {
      "abstract": "The Open Access movement has been successful in increasing the number of freely available research papers, but the potential of text and data mining over this corpus is still largely unrealised.",
      "authors": [
        {
          "name": "Petr Knoth"
        },
        {
          "name": "Zdenek Zdrahal"
        }
      ],
      "dataProviders": [
        {
          "id": 86,
          "name": "Open Research Online",
          "url": "https://oro.open.ac.uk"
        }
      ],
      "documentType": "research article",
      "doi": "10.1045/november2012-knoth",
      "downloadUrl": "https://core.ac.uk/download/267312.pdf",
      "id": 267312,
      "language": {
        "code": "en",
        "name": "English"
      },
      "links": [
        {
          "type": "download",
          "url": "https://core.ac.uk/download/267312.pdf"
        }
      ],
      "publishedDate": "2012-11-01T00:00:00",
      "publisher": "CNRI Acct",
      "title": "CORE: three access levels to underpin open access",
      "yearPublished": 2012
    }
  ],
  "search_id": "b1f0c8a2-9f1d-4b0e-9c1a-2f7d3a5e6b40",
  "total_results": 12843
}
```