Semantic Scholar

Get an author via GET /graph/v1/author/{author_id}. Fetch one author by their Semantic Scholar author id and return exactly the fields asked for, including nested `papers.*` fields. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

List an author's papers via GET /graph/v1/author/{author_id}/papers. Page through the papers of one author. Only the most recent 10,000 citations or references are reachable through the nested fields here; for the full set of a paper's citations use the citations tool. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging: pass `offset` and `limit` and read `next` from the response, stopping when it is absent -- never on a short page. `total` is present on the searches only. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Search authors by name via GET /graph/v1/author/search. Search authors by name and get a page of matches, each with any author field asked for. Names are matched as plain text with no query syntax, and a hyphenated term yields no matches. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging: pass `offset` and `limit` and read `next` from the response, stopping when it is absent -- never on a short page. `total` is present on the searches only. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Get incremental diff links for a dataset via GET /datasets/v1/diffs/{start_release_id}/to/{end_release_id}/{dataset_name}. Get the sequence of incremental diffs that brings a dataset from a release you already hold up to a newer one, so an existing copy can be updated without downloading it again. Each diff carries an `update_files` list (insert or replace by primary key) and a `delete_files` list (remove). Pass `latest` as the end release for the most recent one. THIS TOOL NEEDS THE CONNECTION'S API KEY, and it is one of only two that do: measured 2026-09-22 it answers 401 {"error":"A valid API key is required"} without one, where the other eighteen answer 200. A 401 here means the connection holds no key (or none reached the request); a 403 means the key it holds was not recognised. Neither is a rate limit. THIS RETURNS LINKS, NOT DATA. The answer is a list of pre-signed S3 URLs for archive files that are frequently multiple gigabytes each; Agentic Fabriq does not fetch them and this tool transfers no file. The URLs are time-limited -- fetch them promptly, and re-request this tool rather than storing them. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Suggest paper query completions via GET /graph/v1/paper/autocomplete. Return minimal records (paper id, title, authors, year) for papers matching a PARTIAL query, for interactive query completion. The query is truncated to its first 100 characters. It is not a search: use the relevance search when the caller wants results rather than completions. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Get a paper via GET /graph/v1/paper/{paper_id}. Fetch one paper by any supported identifier and return exactly the fields asked for, including nested ones such as `authors.affiliations` or `citations.title`. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

List a paper's authors via GET /graph/v1/paper/{paper_id}/authors. Page through the authors of one paper, with any author field the caller asks for (affiliations, hIndex, their own papers). ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging: pass `offset` and `limit` and read `next` from the response, stopping when it is absent -- never on a short page. `total` is present on the searches only. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

List a paper's citations via GET /graph/v1/paper/{paper_id}/citations. Page through the papers that CITE this one -- papers in whose bibliography it appears. Each row carries a `citingPaper` plus the citation's own `contexts`, `intents` and `isInfluential` when asked for. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging: pass `offset` and `limit` and read `next` from the response, stopping when it is absent -- never on a short page. `total` is present on the searches only. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

List a paper's references via GET /graph/v1/paper/{paper_id}/references. Page through the papers this one CITES -- the entries in its bibliography. Each row carries a `citedPaper` plus the citation's own `contexts`, `intents` and `isInfluential` when asked for. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging: pass `offset` and `limit` and read `next` from the response, stopping when it is absent -- never on a short page. `total` is present on the searches only. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Search papers by relevance via GET /graph/v1/paper/search. Search Semantic Scholar's corpus of ~200 million papers by relevance and get a page of matches. `query` is plain text with NO query syntax -- a hyphenated term yields no matches, so replace hyphens with spaces. Narrow with `year`, `venue`, `fieldsOfStudy`, `publicationTypes`, `minCitationCount` or `openAccessPdf`. Use this when the caller wants the best matches for a topic; use the bulk search when they want every match, and the title match when they already know the title. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging: pass `offset` and `limit` and read `next` from the response, stopping when it is absent -- never on a short page. `total` is present on the searches only. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Search papers in bulk via GET /graph/v1/paper/search/bulk. Retrieve up to 1,000 papers per call without relevance ranking, continuing with the `token` the previous call returned until no token comes back -- up to 10,000,000 papers in total. Unlike the relevance search, `query` here DOES support boolean syntax: `+` AND, `|` OR, `-` NOT, `"..."` phrase, `*` prefix, `(...)` grouping and `~N` fuzzy/proximity. Nested paper data (citations, references) is not available through this route; for a larger job than this, use the bulk datasets. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Paging here is a CONTINUATION TOKEN, not an offset: repeat the identical query with the `token` from the previous response until the response carries none. Up to 1,000 papers per call and 10,000,000 in total. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Match a paper by title via GET /graph/v1/paper/search/match. Return the SINGLE paper whose title most closely matches the query, with a `matchScore`. Use it to resolve a citation string or a title a user typed into a paper id. A query that matches nothing answers 404 with 'Title match not found' -- that is a miss, not a failure. A miss is HTTP 404 with 'Title match not found', not an empty result: that is the answer 'no paper has a title close to this', not a broken call. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Recommend papers like one paper via GET /recommendations/v1/papers/forpaper/{paper_id}. Recommend papers similar to ONE paper. `from` chooses the pool: `recent` (the default -- recent papers across all fields) or `all-cs` (the whole computer-science corpus). ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

List dataset releases via GET /datasets/v1/release. List every available bulk-dataset release, oldest first, each identified by a date stamp such as `2026-09-16`. Start here before asking for a release's datasets or download links, and note that `latest` is accepted wherever a release id is. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

List the datasets in a release via GET /datasets/v1/release/{release_id}. Describe one release: its README, its licence, and the list of datasets it contains with a short description of each. Pass `latest` for the most recent release. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Get download links for a dataset via GET /datasets/v1/release/{release_id}/dataset/{dataset_name}. Get the pre-signed S3 download URLs for one dataset in one release, along with its README and licence. THIS TOOL NEEDS THE CONNECTION'S API KEY, and it is one of only two that do: measured 2026-09-22 it answers 401 {"error":"A valid API key is required"} without one, where the other eighteen answer 200. A 401 here means the connection holds no key (or none reached the request); a 403 means the key it holds was not recognised. Neither is a rate limit. THIS RETURNS LINKS, NOT DATA. The answer is a list of pre-signed S3 URLs for archive files that are frequently multiple gigabytes each; Agentic Fabriq does not fetch them and this tool transfers no file. The URLs are time-limited -- fetch them promptly, and re-request this tool rather than storing them. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Search text snippets via GET /graph/v1/snippet/search. Search the TEXT of papers rather than their metadata: returns ~500-word excerpts drawn from a paper's title, abstract and body (never figure captions or the bibliography), ranked best first, each with the paper it came from. Use it to find the passage that says something, not the paper that is about something. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Get many authors at once via POST /graph/v1/author/batch. Look up many authors in one call: send the author ids in the body's `ids` array and get one record per id. `fields` is a QUERY parameter on this route, not a body field -- Semantic Scholar's own note, and a `fields` key inside the body is ignored. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Get many papers at once via POST /graph/v1/paper/batch. Look up many papers in one call: send up to 500 identifiers in the body's `ids` array and get one record per id, in the order sent, with `null` in the position of an id that matched nothing. Prefer this over calling the single-paper tool in a loop. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.

Recommend papers from examples via POST /recommendations/v1/papers. Recommend papers from EXAMPLES rather than from a query: send `positivePaperIds` (papers like the ones wanted) and optionally `negativePaperIds` (papers to steer away from). Use the single-paper recommendation tool when there is only one example. ASK FOR WHAT YOU NEED: without `fields` the answer is minimal (the id plus one headline field). Request nested data with periods (`authors.affiliations`, `papers.year`). A single response is capped at 10 MB and an oversized one is refused with 400 rather than truncated, so narrow `fields` or lower `limit` instead of retrying. Read-only: Semantic Scholar publishes no write API, so this changes nothing at Semantic Scholar and nothing is stored there. RATE LIMIT: unauthenticated traffic shares ONE GLOBAL 1000 requests/second bucket with every other caller on the internet, and a connected API key gets its own bucket starting at 1 request/second. So HTTP 429 arrives unprovoked -- measured 2026-09-22 on the first request of a session and between requests four seconds apart -- and it says NOTHING about this connection or its credential: do not re-paste a key, wait and retry with exponential backoff, and serialise rather than parallelise a batch of calls.