Fiscal Data answers with no key, no rate-limit header, and a 400 for a typo'd filter

What it covers

Fiscal Data is the U.S. Department of the Treasury's REST API for public finance records: national debt, currency exchange rates, government spending, and savings bonds. A live GET this session to /v2/accounting/od/debt_to_penny, sorted oldest first, returned the first record on file: 1993-04-01, with a total public debt of $4,225,873,987,843.44. The same endpoint sorted newest first returned 2026-08-25 as the latest record, giving a span of over 33 years.

The debt series holds 8,379 daily records in total, per the meta.total-count field. At a page size of one record, that comes to 8,379 pages. A second endpoint, /v1/accounting/od/rates_of_exchange, filtered to Japan, showed 104 quarterly records, the newest dated 2026-06-30. Treasury updates that series once a quarter, not daily.

Every response carried a meta block naming each field's label, data type, and display format. A caller can build a table straight from that block without hardcoding column names.

No key, and no rate-limit header on any response

No key or sign-up was needed for any call this session. This matches the auth: None already on file. Five calls sent back to back to the same endpoint each came back 200, and none carried a rate-limit, retry-after, or quota header of any kind.

This does not prove there is no limit. It only shows that Fiscal Data does not surface one in its response headers the way some APIs do. A caller has no live signal of how close it sits to any cap Treasury enforces on its side.

Every response also set two cookies: a session cookie and a load-balancer routing cookie from a BIG-IP appliance. Neither cookie is documented as required, and this session sent no cookie back on later calls without any change in behaviour.

The query grammar rejects bad input with a plain 400

This session asked for page[number]=99999 on the debt series, which only runs to page 8,379 at one record per page. The API answered 400 Bad Request with a plain message: "Page #99999 is out of range." It does not clamp to the last page or return an empty list.

A second bad-input probe sent filter=bogus_field:eq:1, naming a field that does not exist on that endpoint. The API answered 400 again, with "Field 'bogus_field' does not exist." Both errors named the exact problem in plain text, so a caller does not have to guess which parameter failed.

CORS is wide open, headers and all

A live GET with an Origin header of https://greatapis.com returned Access-Control-Allow-Origin: *. An OPTIONS preflight against the same endpoint returned 204, with the same wildcard origin, Access-Control-Allow-Methods: GET, POST, OPTIONS, and an Access-Control-Max-Age of 86,400 seconds, one full day. This means a browser can cache a passed preflight for a day before it repeats one.

The same preflight response also carried Access-Control-Allow-Credentials: true alongside the wildcard origin. Browsers ignore that pairing for a plain fetch: a wildcard origin blocks credentialed requests regardless of this header, so it has no practical effect here. This confirms the cors: yes already on file, for the plain, non-credentialed case a browser actually uses.