OpenAlex is a free, CC0-licensed catalog of the global research system, and for most institutional uses — pulling a researcher’s current output list, resolving a work by DOI, or building an analytics rollup for a CRIS — the way that data actually gets consumed is through its REST API rather than the website’s search box. This guide covers the API itself: base URL and entity endpoints, authentication and the 2026 pricing model, how filtering and pagination actually work, and when to use the API at all versus pulling the full bulk snapshot instead. For a broader introduction to what OpenAlex is, its history, and how it compares to Scopus, Web of Science, and Semantic Scholar, see CASRAI’s OpenAlex overview guide.
Base URL and Entity Endpoints
The API is served from api.openalex.org, with one endpoint per entity type. Each entity has its own stable ID and its own collection endpoint:
- /works — journal articles, preprints, books, datasets, and other scholarly outputs.
- /authors — disambiguated person-level records, linked to an ORCID iD where available.
- /sources — journals, conference proceedings, repositories, and preprint servers.
- /institutions — universities, hospitals, companies, and other organizations, linked where possible to a ROR ID.
- /topics — OpenAlex’s subject-classification hierarchy, developed with Leiden University’s CWTS.
- /publishers and /funders — organization-level records used for institutional or funder reporting rollups.
Every entity resolves out to the others — a Work record carries its Authors, its Source, its Authors’ Institutions, its Topics, and any Funders acknowledged — which is what makes the API usable as a connected graph rather than seven unrelated tables. A single work can also be fetched directly by its OpenAlex ID or, more commonly for research-administration use, by DOI: appending a DOI to the /works endpoint returns the matching record without a separate search step.
Authentication and the Current Pricing Model
OpenAlex does not require an account for casual, low-volume use, but the documented, recommended path is to register for a free API key at openalex.org and pass it with every request. In February 2026, OpenAlex introduced usage-based pricing for the hosted API: every key receives a modest daily free-usage allowance, and single-record lookups by ID or DOI remain free regardless of volume — only heavier bulk search and filter traffic draws down the metered allowance. Institutions needing higher limits, monthly full snapshots, or daily change files can arrange a paid plan directly with OurResearch.
It’s worth being precise about what changed and what didn’t: the API — the hosted, on-demand query service — now has a metered cost structure for heavy use. The underlying data remains CC0-licensed and free to download in full as a bulk snapshot, with no paywall on the dataset itself. An institution that wants to avoid API costs entirely at scale can still sync the whole graph via the snapshot and query it locally (see below) rather than paying per call.
Building Queries: Filter, Search, Select, and Group-By
Beyond simply listing an entity type, the API supports several query parameters that make it usable for real institutional reporting rather than just browsing:
- filter — narrows a collection to records matching specific field values, such as works published in a given year, by a given institution, or with a given open-access status. This is the parameter that turns “give me all works” into “give me this institution’s 2025 works.”
- search — runs a full-text query across titles and, where available, abstracts, for keyword-style lookups rather than exact field matching.
- select — limits which fields are returned per record, useful for trimming payload size when only a few fields (say, title and DOI) are actually needed.
- group_by — returns aggregate counts by a field instead of individual records, which is the practical way to build a rollup (works per year, works per funder, works per open-access status) without paginating through every underlying record and counting client-side.
Filter and search parameters can be combined in a single request, and results can be sorted by relevance or by a chosen field. Responses are returned as JSON with a consistent shape: a meta block carrying the total result count and paging state, and a results array (or, for group-by queries, a group_by array of counts) carrying the actual records.
Pagination: Basic Paging vs. Cursor Paging
OpenAlex supports two distinct pagination methods, and picking the wrong one is the most common practical mistake when pulling more than a handful of records:
- Basic pagination uses
page(default 1, allowed range 1–500) andper_page(default 25, allowed range 1–100) parameters. This method has a hard ceiling:pagemultiplied byper_pagecannot exceed 10,000, meaning basic pagination alone cannot retrieve more than the first 10,000 results of any query, regardless of how many total records match. - Cursor pagination is required to go beyond that limit. A request starts with
cursor=*; each response includes anext_cursorvalue in its metadata, which is passed as thecursorparameter on the next request. The sequence continues untilnext_cursorcomes backnull, indicating the last page has been reached. Cursor pagination works alongside filtering and works with grouped results, and it’s the correct approach for any query — such as “every work affiliated with this institution since 2015” — that plausibly returns more than 10,000 records.
OpenAlex’s own documentation is explicit that cursor pagination is not intended as a mechanism for downloading the entire dataset. For that use case — syncing the whole graph, or a whole entity type, for local analytics — the bulk snapshot is the intended path, not repeated cursor-paged API calls.
When to Use the API vs. the Bulk Snapshot
The API and the full snapshot solve different problems, and choosing between them is really a question of access pattern:
- Use the API for on-demand, targeted lookups: resolving a single work by DOI, checking whether a researcher’s latest publication has been indexed yet, or pulling a specific institution’s works for a one-off report.
- Use the bulk snapshot — a complete, periodically refreshed dump distributed as newline-delimited JSON and Parquet files in a public, anonymously-accessible Amazon S3 bucket, with no AWS account or sign-up required — for building a local research-analytics database or CRIS backend. Rather than metering per-call usage against hundreds of thousands or millions of records, an institution pulls the whole graph once, refreshes it on a schedule, and queries it locally under the same CC0 terms.
For most institutional infrastructure builds — a faculty-output dashboard, a CRIS ingest pipeline, an institutional open-access monitor — the snapshot is the more sustainable long-term choice; the API is better suited to interactive tools and low-volume lookups where a live, always-current answer matters more than local control over the data.
Client Libraries
Because the API returns plain JSON over HTTP, it can be queried with any standard HTTP client, but the OpenAlex community maintains dedicated wrapper libraries in the two languages most common for research-analytics work: pyalex for Python and openalexR for R. Both wrap the same filter/search/select/group_by/cursor mechanics described above in language-native syntax, handle cursor pagination automatically, and are the more common starting point than hand-rolled HTTP calls for anyone building a recurring institutional pipeline rather than a one-off script.
Practical Use Cases for Research Administration
- DOI resolution: confirming a work is indexed and pulling its full metadata, authorship, and open-access status by DOI, useful when reconciling a publication list against what OpenAlex has captured.
- Institutional output rollups: using
filterplusgroup_byto count an institution’s works by year, funder, or open-access status for an annual report, without needing to paginate through every underlying record. - Author disambiguation checks: looking up a researcher’s OpenAlex Author record, cross-checked against their ORCID iD, before ingesting their output list into a CRIS or faculty-reporting system.
- CRIS or analytics backend ingest: using the bulk snapshot rather than the API for a scheduled, large-scale sync, per the guidance above.
Frequently Asked Questions
Do I need an API key to use the OpenAlex API?
Not strictly for casual, low-volume use, but it’s the documented and recommended path: a free API key gives you a daily usage allowance under the pricing model introduced in February 2026, and single-record lookups by ID or DOI stay free regardless of volume.
How many results can I get with basic pagination?
Up to 10,000 total — the constraint is that page multiplied by per_page cannot exceed 10,000. Anything beyond that requires cursor pagination.
Is the OpenAlex API the same thing as the OpenAlex data?
No, and the distinction matters for cost. The API is a hosted, metered convenience service for on-demand queries. The underlying data is CC0-licensed and free to download in full via the bulk snapshot, independent of API usage limits.
What’s the difference between this page and CASRAI’s general OpenAlex guide?
The OpenAlex overview guide covers what OpenAlex is, its history as a successor to Microsoft Academic Graph, its entity model, and how it compares to Scopus, Web of Science, and Semantic Scholar. This page is scoped specifically to the API itself — endpoints, authentication, query parameters, and pagination mechanics — for readers who are building or evaluating an integration rather than evaluating OpenAlex as a data source.
Should I use pyalex/openalexR or call the API directly?
For a recurring institutional pipeline, a client library is generally easier to maintain: pyalex (Python) and openalexR (R) handle cursor pagination and parameter formatting for you. For a one-off lookup or a system in a language without a dedicated wrapper, calling the JSON API directly with any HTTP client works just as well.







