Summary

I work on the Fermi LAT data-server infrastructure at NASA/GSFC. The
LATDataQuery.cgi endpoint that astroquery.fermi submits queries to is
being replaced by a JSON REST API, now live at:

• Docs: https://fermi.gsfc.nasa.gov/ssc/data/access/lat/lat_data_query_doc.html
• Base URL: https://fermi.gsfc.nasa.gov/ssc/data/access/lat/query/api/v1

New API in brief

POST /query              -> {"query_id": ...}       (JSON payload)
GET  /query/{id}/status  -> {"state": ...}
GET  /query/{id}/results -> {"files": [{"name": ...}, ...]}

Files are staged on the HEASARC FTP area as before. Most request field names
were deliberately kept compatible with the CGI form fields
(coordfield, coordsystem, shapefield, timefield, timetype, energyfield,
photonOrExtendedOrNone, spacecraft), and a
new optional zenithangle parameter was added. coordfield accepts either
"RA,Dec" or a target name, coordsystem accepts J2000, B1950 or
Galactic, and all-sky queries are supported with a radius > 60 degrees and
an observation window of <= 24 hours.

What this means for astroquery

I have a rewritten astroquery/fermi module ready as a PR:

• FermiLAT.query_object() keeps its existing signature — end-user
  scripts should not need to change.
• All HTML scraping is removed; the module speaks JSON only.
• query_object_async() now returns the server's query_id instead of a
  results-page URL.
• Invalid queries are rejected with a JSON error body {"error": "..."}, which the module now surfaces to users — this addresses the long-open Fail with useful failure messages on genuine failures. #1849.
• New capabilities exposed: get_status(), list_results(),
  wait_for_completion(), get_file_urls(), plus zenithangle and all-sky queries.
• GetFermilatDatafile / get_fermilat_datafile retained as deprecated
  shims.
• Unit tests rewritten against mocked JSON responses; remote tests verified
  end-to-end against the live API (all passing as of 2026-08-14).

I'll open the PR shortly and link it here. Feedback welcome on the approach —
in particular on the deprecation handling and on whether the module's
"Experimental" import warning should be dropped as part of this change (the
PR currently drops it).