Issue Nº 27 — Sep 10, 2026
Chronicling America's pagination has two counters, and they count different things
Issue twenty-seven covers Chronicling America, the Library of Congress's archive of historic US newspaper pages. Its search API needs no key. This session queried it live. One field counts items and a second counts pages, one documented endpoint hides its rows a level deeper than the response's top, and the retired old host now forwards through two HTML redirects instead of answering in JSON.
of counts items, total counts pages
GET /collections/chronicling-america/?q=telegraph&fo=json, queried live this session, returned 200 with pagination.of: 3219310 and pagination.total: 80483. The first number is how many pages of newspaper text matched. The second is how many result pages the API split them across, at 40 per page.
A search for a nonsense term, queried live this session, returned 200 with pagination.of: 0 and pagination.total: 1. Zero matches still gets one page, because a page listing zero results is still a page.
Code that reads pagination.total expecting a count of matches will report one result for a search that found none, and a few dozen for a search that found three million.
The titles endpoint's rows are not where the top level says
GET /collections/chronicling-america/titles/?fo=json, queried live this session, returned 200. Its top-level pagination.of read 4609 and pagination.total read 185, so the response promised rows.
But the top-level results field was absent. The 25 title records for that page live one level down, at content.results, and content.pagination duplicates the top-level pagination object exactly.
A caller that reads the search endpoint's shape, where results sits at the top level, and reuses it here will parse an empty response for an endpoint that actually holds 25 title records.
The retired host and a missing collection both answer with more than an error code
GET https://chroniclingamerica.loc.gov/, the pre-2025 host, queried live this session, returned 308 to https://www.loc.gov/chroniclingamerica/, which itself returned 301 to https://www.loc.gov/collections/chronicling-america/. Both hops serve HTML, not JSON, so a JSON client that follows redirects blindly gets a web page back.
GET /collections/no-such-collection-xyz/?fo=json, queried live this session, returned 404 with a JSON body. That body carried exception: "not found". It also carried a caption block holding a photo title, a photographer credit, and a tile.loc.gov image URL, left over from a shared error template.
The photograph in that block is not fixed. Three different unknown collection paths, queried in the same session, returned three different pictures: a 1918 Navy portrait, a 1936 farm scene, and a view of the Library's Main Reading Room. Each response carries cache-control: max-age=300, so one path repeats its own caption for five minutes before it can change.
Neither failure is a plain error. One needs redirect-chasing code that checks content-type before trusting the body; the other needs code that reads exception rather than assuming any JSON body means success.
Chronicling America, by the numbers
- GET/collections/chronicling-america/?q={query}&fo=json
- GET/collections/chronicling-america/titles/?fo=json