PubMed API 教程：用 Python 调用 E-utilities 检索与抓取文献

The PubMed API is the starting point for biomedical record retrieval: search for identifiers, fetch citation records and available abstracts, then discover linked records. NCBI exposes these operations through E-utilities rather than requiring a PubMed scraper.

But retrieving a paper is not the same as answering, “Which dose was tested, in how many participants, and with what outcome?” This guide builds the retrieval workflow in Python, then shows where the SciSpace API takes over: reading full text, extracting trial data and writing up the evidence.

How does the PubMed API work?

An Entrez PubMed integration uses the shared E-utilities base URL shown in the code below. Set db=pubmed for searching and fetching PubMed records.

These are retrieval operations, not a trial-data extraction service. In particular, a full PubMed record is not the full article.

Keep the PMID attached to every downstream object: abstract, full-text file, extracted field and citation. That gives your application a consistent reconciliation key.

Do you need a PubMed API key?

Not for this small example. As of October 21, 2026, NCBI documents default allowances of three requests per second without a key and ten with a key. Unkeyed requests share an IP allowance; requests using the same key share its allowance across machines.

Create an NCBI API key in your NCBI account settings if needed, and pass it through api_key. Include a descriptive tool and your contact email; follow NCBI's registration guidance for deployed integrations.

Search PubMed with ESearch

Our example searches for semaglutide and obesity randomized-trial records published from 2021 through 2025. It is a development query, not a validated systematic-review strategy.

PubMed Advanced Search supports [tiab] for title/abstract, [pt] for publication type and [dp] for publication date. Publication-type restrictions can miss records whose indexing is incomplete.

Install requests with python -m pip install requests, and set the environment variable NCBI_EMAIL to your real contact address. This compact example performs ESearch followed by EFetch; it intentionally retrieves only five records. The request parameters follow NLM's utility documentation.

Before expanding the example, inspect result for warnings, errors and querytranslation. Save both the submitted expression and its translation. Maintain a few expected-included papers as regression fixtures rather than trusting the match count alone.

Fetch abstracts in Python with EFetch

The preceding code leaves the XML response in root. For journal articles, iterate over root.findall('PubmedArticle'), then read the PMID from MedlineCitation/PMID and article fields beneath MedlineCitation/Article. NLM's XML examples illustrate this record structure.

In your parser, preserve structured abstract sections and their labels. Use ''.join(element.itertext()) for text containing nested markup, and store an absent abstract as missing data rather than an empty clinical finding.

Store a search, then page through its records

For larger, bounded searches, add usehistory=y to ESearch. Its webenv and querykey values become EFetch's WebEnv and query_key parameters; retstart and retmax select batches without resending every PMID.

Persist your selected identifiers locally as well. Compare fetched and parsed counts against the expected batch size, and explicitly handle unsupported record types instead of silently dropping them.

How do you handle the PubMed retrieval ceiling?

NCBI's reference, updated March 4, 2026, documents that PubMed ESearch retrieves only the first 10,000 matching records. Increasing retstart or adding a History handle is not an unlimited-pagination strategy.

NCBI recommends segmenting oversized searches, for example by date, into sets below 10,000, or using EDirect's additional batching logic. Deduplicate the resulting PMIDs and record each partition's query and retrieval timestamp.

For a local PubMed mirror, use the annual baseline and daily updates rather than treating ESearch as a bulk-export mechanism. Updates contain revised and deleted citations as well as new records.

Use ELink to resolve PMC connections

ELink can discover PMC counterparts through dbfrom=pubmed, db=pmc and linkname=pubmed_pmc. Repeat the id parameter to preserve the correspondence between each input PMID and its linked identifiers.

Append this to the earlier example:

Keep PMC identifiers separate from PMIDs. ELink discovers connections; it does not download the linked article.

Use approved PMC retrieval services for full text and inspect article-specific permissions. A PMC connection is not blanket permission to redistribute its content.

Prevent silent failures before shipping

The examples show the essential requests, not a production client. Add these safeguards around them:

• Validate bodies: check JSON and XML errors, not only HTTP status.
• Coordinate requests: use shared pacing across workers and back off on transient failures.
• Reconcile counts: track matched, fetched, parsed and rejected records separately.
• Test edge cases: include missing abstracts, structured sections and unexpected record types.
• Preserve provenance: retain raw responses, identifiers, query configuration and retrieval timestamps.

Shared pacing matters because NCBI's keyed allowance applies across machines using that key. If you add a key to the example, put it in common so every request includes it.

Where retrieval stops: outcomes, doses and sample sizes

E-utilities supplies records and links, leaving your product to implement evidence extraction and cross-paper synthesis. That division follows from its documented retrieval functions.

Define your extraction contract before choosing a model:

Keep original units alongside normalized values. Require review of the supporting passage before accepting a number into an evidence product.

Beyond PubMed retrieval, a custom implementation needs full-text discovery, PDF fetching and parsing, extraction prompts, citation assembly and summarization. Broader discovery adds multiple source clients, source-specific request handling, deduplication and ranking.

For document-first workflows, see the PDF data extraction API tutorial.

From PubMed records to finished evidence: the SciSpace API

The extraction table above is where most PubMed projects stall. E-utilities hands you PMIDs, abstracts and links. Reading full text, pulling out doses and sample sizes, checking trial registries and writing it up is left to you.

The SciSpace API puts the full SciSpace Agent behind one call. It searches, reads, analyses and writes, and delivers the result as ready-to-use files. It comes as two APIs:

What this adds on top of E-utilities

• Evidence beyond PubMed. One task can search papers and 11 national and regional clinical-trial registries plus the WHO registry, along with public science databases such as PubChem, ChEMBL, UniProt and ClinVar.
• The extraction table, filled from full text. Describe the columns you need (randomized N, dose, route, primary outcome, timepoint) and the Task API fills them from the papers' full text where it's available. You can then filter, sort and combine the results.
• Systematic reviews with a PRISMA flow diagram. The Task API sets research questions, screens up to 3,000 papers, extracts data and writes the report, including the PRISMA flow diagram.
• Finished files, not just an answer. One run can return a Word document, a LaTeX report compiled to PDF with its BibTeX, a PowerPoint deck or plots. You get links to every file it created.
• Progress you can show users. A review can take minutes. The Task API streams each plan step and the answer as it's written. When it finishes, send follow-ups in the same thread, such as "split analyzed N by arm" or "add a column for adverse events".
• Questions over your own PDFs. Upload up to 10 PDFs at once and get answers with page-level citations, including content read from figures and tables.

When to use which

• Use E-utilities alone for a PubMed citation feed, an abstract export or a local mirror built from the annual baseline and daily updates.
• Use the SciSpace API when the output your users need is an extraction table, a systematic review or a written report. You can keep E-utilities alongside it and pass the PMIDs you already trust into the task. For registry data on its own, see the ClinicalTrials.gov API guide.

What it doesn't do

• No paywalled papers. SciSpace reads your own PDFs plus 50M+ open-access full texts. Where only an abstract is available, ask the task to label that evidence abstract-only.
• Not a PubMed mirror. For complete, up-to-date PubMed coverage, use NCBI's baseline and update files.
• Keep a human check. Review the supporting passage before a number goes into an evidence product, the same rule as in the extraction table above.

The SciSpace API is in early access; it isn't open yet. At launch it's open to anyone: register on SciSpace and start, with no sales call. Every account gets $5 in free API credits, enough to try both APIs on real questions. The API is separate from SciSpace consumer plans; no consumer plan includes API usage.

Frequently asked questions

Sources

1. NLM: What Is an API Key and How Can I Get It?
2. NLM: The E-utilities and Associated Parameters
3. NLM: E-utilities and the History Server
4. PubMed User Guide
5. NLM: Download PubMed Data
6. PMC: For Developers

注意转载授权 · 阅读原文