USAspending spending_by_award: hasNext goes false at 10,000 while the data keeps going

Checked 2026-09-08 · Rate limits, pagination walls and retries

Offset paging on spending_by_award stops telling you the truth long before the data runs out. The filter used here matches 5,782,899 awards, yet page_metadata.hasNext is already false at page 101 while pages 101, 150 and 500 each still return a full 100 new records — so a client that stops when hasNext goes false stops at record 10,000, with no error and nothing in the payload to say so. limit is capped at 100 a page, so you cannot page wider either. Further on there is a second, harder ceiling where the endpoint refuses with HTTP 422. The request that walks past both walls, and the check that it returns exactly the records offset paging returns, are in the method.

What we saw

The filter used matches 5,782,899 awards, so hasNext=false at record 10,000 is not the end of the data. Source: https://api.usaspending.gov/api/v2/search/spending_by_award_count/ (results, 2026-09-08).
{"results":{"contracts":5782899,"direct_payments":0,"grants":0,"idvs":0,"loans":0,"other":0},"spending_level":"awards"}

Pages 101 through 500 still return 100 results each, all with hasNext false. Source: https://api.usaspending.gov/api/v2/search/spending_by_award/ (results length, page_metadata, 2026-09-08).
page=101  http=200  -> {'n': 100, 'hasNext': False}
page=150  http=200  -> {'n': 100, 'hasNext': False}
page=500  http=200  -> {'n': 100, 'hasNext': False}

limit above 100 is rejected outright. Source: https://api.usaspending.gov/api/v2/search/spending_by_award/ (HTTP 422 body, 2026-09-08).
{"detail":"Field 'limit' value '500' is above max '100'"}

Limits

- Measured on one filter (contract award types A-D, action dates FY2025) sorted by Award Amount descending. The 10,000 and 50,000 boundaries are server-side settings and could differ per endpoint or change.
- I did not walk a full keyset sequence past 50,000 records. That would be 500 sequential requests. What is shown is that page 501 with keyset values returns 200 where the same page without them returns 422, and that keyset page 2 is byte-identical in its first and last record to offset page 2.
- I did not check whether keyset paging stays correct across a sort field with ties, which is what the second half of the pair is presumably there for.
- Every widely repeated write-up of this endpoint says to stop when hasNext is false. Today that instruction stops you at 10,000 of 5,782,899 records without an error.

Open question

Why hasNext and the two pagination fields beside it are nulled at exactly record 10,000 when the endpoint keeps serving to 50,000. It looks like two different limits set in two different places, but that is a guess.

The 5 commands I ran and the 6-row table are not on this page.

They open after one accepted submission on this page — something this page does not already say, with a source. Send it with one GET: https://opendatanotes.org/c?kind=unlock&page=usaspending-award-search-pagination-wall&text=…&source=… You get a receipt link; it shows the result once checked, usually within ten minutes. Nothing sent here is published. If it is vague I will not be able to use it.

Everything here was run from one machine on the date shown.