How to Scrape DBLP Publications, Authors & Venues in 2026

DBLP is the largest open bibliography of computer-science publications, and its search API is fully public — but if you’ve tried to build a real dataset from it, you’ve hit the same wall everyone does: the web UI shows a page at a time, and hand-collecting a decade of papers on a topic is a non-starter. The API can return over a hundred thousand results for a broad query like “neural networks,” and you need to page through all of it, normalize the messy per-record fields, and dedupe. This guide covers how DBLP’s search API is shaped, what you can pull, and how to turn a keyword into a clean multi-thousand-row dataset — no API key, no login.

What’s worth extracting

A publications search returns 13 fields per record:

• Bibliographic core — title, authors (comma-separated author names), venue (conference name or journal title), and year.
• Type and identifiers — type (“Journal Articles”, “Conference and Workshop Papers”, etc.), doi, and key (DBLP’s internal record key, e.g. journals/nn/Smith24).
• Links — ee (the electronic-edition full-text URL, often open access) and url (the DBLP record page).
• Detail — pages (page range) and volume (journal volume).
• Signals — access ("open" when free full-text is available) and mode (the search mode that produced the row).

The key field is the one to build on: it’s a stable, unique identifier per record, structured as type/venue/AuthorYear. Use it to dedupe across runs and to construct direct DBLP record URLs.

The actor also has two other modes that reuse the same output columns with different meaning. In authors mode, title/authors hold the researcher name, venue holds affiliations, and volume holds awards (e.g. “Turing Award”). In venues mode, title/venue hold the venue name, key/volume hold the acronym, and url links to the DBLP venue page.

How the source actually works

DBLP exposes three official public search endpoints, all returning JSON natively — no HTML parsing, no browser:

https://dblp.org/search/publ/api    # publications
https://dblp.org/search/author/api  # authors
https://dblp.org/search/venue/api   # venues

The actor queries these in bulk and paginates automatically in pages of up to 1,000 records. You pick a mode, give it a query, and set maxResults. A publications sweep:

{
  "mode": "publications",
  "query": "transformer attention mechanism",
  "maxResults": 1000,
  "proxyConfiguration": { "useApifyProxy": true }
}

An authors lookup:

{
  "mode": "authors",
  "query": "Yoshua Bengio",
  "maxResults": 50,
  "proxyConfiguration": { "useApifyProxy": true }
}

One behavior worth knowing up front: DBLP adds wildcards to your terms internally, so neural network matches “neural networks”, “neural networking”, and so on. That’s helpful for recall but means broad single words return enormous, noisy result sets. Multi-word queries like graph neural network node classification are far more precise.

▶ Open the DBLP Scraper on Apify — one run turns a keyword into thousands of CS paper records with titles, authors, venues, DOIs and full-text links. Keyless, no login. Export to CSV, JSON or Excel.

The access reality

DBLP is operated by Schloss Dagstuhl and its API is documented and open, so this isn’t an anti-bot problem — it’s a volume-and-etiquette problem:

• Results can be huge. The README notes DBLP reports 112,000+ results for broad queries like “neural networks.” You cap the run with maxResults (1–10,000); the actor pages through DBLP’s 1,000-per-request API until your limit is reached or results are exhausted. Above 10,000, narrow the query.
• Politeness matters. A public academic API is a shared resource. The actor paces requests, routes through datacenter proxy (which is sufficient here), and retries transient network errors — rather than hammering the endpoint.
• Metadata only. DBLP indexes bibliographic metadata, not full paper text. The ee URL points to the full text elsewhere (publisher, arXiv, proceedings), which is often but not always open access.
• Freshness lag. DBLP updates continuously as publishers submit records; papers typically appear within days to weeks of publication. For the very latest preprints, query arXiv directly alongside DBLP.

The naive approach — one API call, first page only — misses 99% of a large query and forces you to hand-roll the 1,000-per-page pagination and retry logic. The actor solves the paging once.

Example output

One publications record:

{
  "title": "Communication-Efficient Learning of Deep Networks from Decentralized Data",
  "authors": "H. Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson, Blaise Agüera y Arcas",
  "venue": "AISTATS",
  "year": "2017",
  "type": "Conference and Workshop Papers",
  "doi": "10.48550/arXiv.1602.05629",
  "ee": "http://proceedings.mlr.press/v54/mcmahan17a.html",
  "key": "conf/aistats/McMahanMRHA17",
  "pages": "1273-1282",
  "volume": "54",
  "url": "https://dblp.org/rec/conf/aistats/McMahanMRHA17",
  "access": "open",
  "mode": "publications"
}

Typical use cases

Who pulls DBLP data and why:

• Systematic literature reviews — build a dataset of every neural-network paper in the last decade for a meta-analysis, filtered by year and venue.
• ML dataset construction — assemble corpora of CS papers (titles, DOIs) for training or benchmarking.
• Author output mapping — run a name in publications mode to get a researcher’s full publication list; switch to authors mode for the profile with affiliations.
• Venue discovery — search a topic abbreviation like NeurIPS or CVPR in venues mode to get official venue metadata, or find the dominant venues in a niche like “federated learning.”
• Trend tracking — count papers mentioning a keyword year-over-year to quantify a subfield’s growth.
• Institution analysis — run multiple author-mode queries for names tied to a university and aggregate by affiliation.

Cost and effort: build vs. managed

Because the API is JSON and keyless, the DIY version isn’t hard to start — but the parts that make it useful are the parts you have to build and maintain: correct 1,000-per-page pagination to the 10,000 ceiling, retry-with-backoff on transient errors, the three mode variants, dedup on key, and a schedule if you want a recurring sweep. That’s a small pipeline, and it drifts when DBLP tweaks response shapes.

The managed actor is pay-per-result: a small per-run start fee plus a fraction of a cent per record, no subscription. Runs are fast — the README puts 500 results at under 30 seconds and 5,000 at roughly 2–5 minutes, most of which is network latency and proxy routing. Because you pay per record, validating a query at maxResults 500 costs almost nothing before you scale to a 5,000+ sweep.

Common pitfalls

Specific to DBLP:

• Empty fields are normal. Not every paper has a doi, pages or volume — arXiv preprints and informal publications especially. The ee URL is the most reliable link to the actual paper; don’t drop rows just because the DOI is blank.
• Match mode to intent. An author name in publications mode returns their papers; the same name in authors mode returns the profile. Searching the wrong mode is the most common “why zero/weird results” cause.
• Broad single words are noisy. Because DBLP auto-wildcards, graph matches an ocean of unrelated work. Use specific multi-word phrases to keep results relevant and the run small.
• Dedupe on key. Across overlapping queries (a topic sweep plus an author sweep) the same paper recurs. The DBLP key is the stable unique identifier — dedupe on it, not on title.
• Author disambiguation. Common names collide. If a query returns papers from multiple people, add a co-author or institution keyword to disambiguate.
• Cap above 10,000. A single query maxes at 10,000 via the actor. For a topic with more results, split by year ranges or narrow the phrase rather than expecting the full 112k in one run.

Wrapping up

DBLP is a clean, keyless, JSON-native source for computer-science bibliography — the only real engineering is paging through very large result sets politely and normalizing the sparse per-record fields. If you’d rather turn a keyword straight into a multi-thousand-row dataset without building the pagination and retry layer, the managed actor does it.

▶ Run the DBLP Scraper on Apify — a single keyword run yields thousands of CS publication records with titles, authors, venues, years, DOIs, full-text links and stable DBLP keys. Keyless, no login. Export to CSV, JSON or Excel. Start on Apify’s free monthly credit.