A Python client for the ATLAS API

Heloise F. Stevance; Jack Leland; Ken W. Smith

REVIEW 3 major objections 6 minor 1 cited by

A Python client for the ATLAS API

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper presents a maintained Python client that wraps every read-write utility of the ATLAS REST API behind a class-based interface.

desk verdict Useful client, but the paper currently gives no way to verify the package exists; the authors need to point to the artifact and back up the 'all read-write utilities' claim. read the letter →

arxiv 2506.06403 v1 pith:GWB5XYYA submitted 2025-06-06 astro-ph.IM

Heloise F. Stevance , Jack Leland , Ken W. Smith This is my paper

classification astro-ph.IM

keywords ATLASsurveyRESTAPIclientPythonsoftwareastronomicaltransientstime-domainastronomyautomatedfollow-uptestingalertstreams

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents atlasapiclient, a Python client that wraps every read-write utility of the ATLAS transient-survey REST API behind a class-based interface. The client hides endpoint URLs and token management, so alert-processing bots and scientists can talk to ATLAS data without reimplementing HTTP plumbing. It ships with unit and integration tests, and the paper argues that this test coverage lets the client absorb ATLAS API changes without breaking users' existing code. A working client matters because ATLAS alert streams already drive automated follow-up observations, and a shared, maintained wrapper gives new projects the same access without building their own.

What carries the argument

The carrying object is the client class interface plus its test suite. The client class methods wrap individual API endpoints so users never construct URLs or handle tokens directly; the test suite (unit tests for parsing and token logic, integration tests against the live server) is what lets the authors ship API-compatible updates without requiring user-side changes. Together they convert a moving REST API into a stable programming surface.

What would settle it

Check whether the package is installable from the public Python package registry and run its integration tests against a live ATLAS API endpoint; if the package cannot be found or the tests fail on the documented endpoints, the central claim collapses.

Watch

Extended reading notes

Core claim

The central claim is that a single maintained Python package can provide complete, ergonomic, and stable access to the ATLAS API. Concretely, atlasapiclient is a class-based interface covering all read-write utilities of the REST API; it abstracts the endpoint URLs and token management, and its unit/integration test suite is the mechanism that allows the client to evolve with the API while user code stays unchanged. The package is already used in the authors' transient-stream processing pipeline and by an automated follow-up telescope, so the claim is not only architectural: it is that the client works on live ATLAS data today.

Load-bearing premise

The load-bearing premise is that the atlasapiclient package is actually published and functional and that the ATLAS API endpoints it wraps are stable as described, a premise the manuscript supplies no repository link or installation instructions to verify.

Editorial extensions

If this is right

Alert-ranking bots can read and write ATLAS data through one documented class interface instead of hand-crafted HTTP calls.
When ATLAS changes an endpoint, only the client needs updating; users' existing code keeps working after a client release.
New science projects can connect to the ATLAS stream with modest effort, as the paper says the client is intended for wider use beyond its original pipeline.
Automated follow-up triggering of nearby transients is already one live use of the client, so the interface is exercised under real observing conditions.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: A maintained wrapper only delivers robustness if the maintainers commit to updating it on the same timescale as API changes; the paper asserts the client is maintained, but the long-term promise depends on that ongoing commitment.
Editorial inference: The test suite's guarantee is only as strong as its endpoint coverage; a reader could quantify the claim by measuring how many of the ATLAS API's documented read-write endpoints have corresponding tests.
Editorial inference: The same decoupling pattern should transfer to other survey alert systems whose APIs evolve, though the paper does not claim that extension.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper describes a Python client for the ATLAS REST API. The need is real: anyone building a bot or a follow-up pipeline for ATLAS has to deal with endpoint URLs, token management, and API breakage, so a maintained wrapper with tests is a legitimate contribution. The design is sensible—abstracting the API surface and decoupling user code from endpoint changes—and the fact that the client is already driving Mookodi follow-up is a decent real-world signal. Credit where it's due: the authors know the problem space and have built something that works for them and at least one other facility.

The soft spot is big: the manuscript does not actually deliver the artifact. There is no repository URL, no PyPI package name, no Zenodo DOI, no installation command, no test output. The only linked resource is the VRA archive, not atlasapiclient itself. The central claim—that a tested, usable client exists—is therefore unverifiable from the paper. That's not a dispute with the community or a subtle methodological issue; it's a simple reproducibility gap. A reader cannot install, inspect, or run the thing being presented. The 'all read-write utilities' claim also needs an endpoint coverage table or at least a list of wrapped endpoints, otherwise it reads as an unbacked promise.

These are fixable in a revision. Add the repository and a released DOI, include a minimal usage example, and state which endpoints are covered. The paper would then be a serviceable software note. As it stands, it's a statement of need and a pointer to a presumably useful package, but not yet a complete software paper.

The citation pattern is fine: the ATLAS papers are relevant, and the self-citation to VRA is an appropriate use case reference, not padding. The writing is clear and honest about the motivation.

Who gets value from this? People who connect tools to the ATLAS API and want a maintained client instead of writing their own. A serious editor should send it to review—but only after asking the authors to make the package accessible and substantiate the coverage claim. If they cannot do that, the paper should not proceed.

Referee Report

3 major / 6 minor

Summary. This short manuscript announces atlasapiclient, a Python client for the ATLAS REST API. The authors state that the client provides a class-based interface to all read-write utilities of the API, abstracts endpoint URLs and token management, and includes a full set of unit and integration tests. They describe its origin in the ATLAS Virtual Research Assistant pipeline and its current use for follow-up observations with the Mookodi telescope, and they argue that a dedicated, tested client will protect user code from API evolution. The manuscript contains a statement of need, a brief data-access note, acknowledgements, and references, but no code, repository link, installation instructions, test output, or endpoint-coverage information for atlasapiclient itself.

Significance. If the package exists and works as described, it would fill a genuine community need: providing a maintained client that isolates bots and external projects from ATLAS API changes, and reducing duplicated effort for groups building alert-follow-up tools. The architectural argument for a dedicated, tested client is reasonable and the reported Mookodi deployment is a concrete use case. However, the significance cannot currently be assessed because the central artifact is absent from the manuscript: there is no way to inspect, install, or test the client, and the claims of complete endpoint coverage and a full test suite are unverifiable. The paper is therefore best viewed as a brief announcement rather than a self-contained software description.

major comments (3)

[Statement of need] The central claim of the paper is that atlasapiclient is a publicly available, maintained Python client, but the manuscript provides no repository URL, PyPI package name, Zenodo DOI, installation command, version number, or any other pointer to the package itself. The only external link is to the VRA Zenodo archive (Heloise & genghisken 2025), which is a separate project. Without an accessible artifact, a reader cannot verify that the package exists, let alone that it functions as claimed. This is a load-bearing omission because the entire paper is an announcement of this software. Please add a direct link to the package repository and/or archive, and include installation and usage evidence in the manuscript.
[Statement of need] The claim that the client provides a class-based interface to 'all the read-write utilities of the API' is a completeness assertion that is not backed by any endpoint list, coverage table, or link to the ATLAS API documentation. A user cannot tell which endpoints are wrapped, whether any are missing, or how the claim was verified. Please provide a coverage list or matrix that enumerates the wrapped endpoints and indicates which are read-only and read-write, with a reference to the official API specification.
[Statement of need] The paper asserts that the package includes 'a full set of unit and integration tests' and that this test suite is the mechanism for maintaining compatibility with API changes, but no test results, test configuration, continuous-integration badge, or coverage report is supplied. Given that the robustness argument rests entirely on this test suite, the absence of any supporting evidence makes the central maintainability claim unverifiable. Please include test execution output, a link to a CI pipeline, or at least a tests/ directory listing in the repository the paper will point to.

minor comments (6)

[Abstract] 'all-sky optical sky survey' is redundant; consider 'all-sky optical survey'.
[Statement of need] In 'Decoupling the user’s code form the implementation of the API', 'form' should be 'from'.
[Statement of need] The phrase 'since early 2025' in the Mookodi sentence is ambiguous: it appears to modify 'has allowed automated triggering and classification', but could be misread as modifying the telescope deployment. Please rephrase for clarity.
[References] The citation 'Heloise, & genghisken' uses informal GitHub handles; please provide full author names as used in the corresponding Zenodo record.
[Data Access] The mention of GDPR-compliant data policies appears without any detail or reference; either expand this sentence or remove it, as its relevance to the client is not explained.
[General] The manuscript lacks a Code Availability section. For a software-oriented paper, even a short statement with the package name, version, and repository URL is essential and should be added.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper presents a software client with no derivation chain, and its self-citations are use-case references, not load-bearing arguments.

full rationale

This is a software description paper, not a derivation. The central claim is that the authors have developed a Python client, atlasapiclient, for the ATLAS REST API. There are no equations, fitted parameters, or predicted quantities that could reduce to inputs by construction. The only self-references are to the authors' own VRA pipeline (Heloise & genghisken 2025) and to the ATLAS survey papers, but these are cited as context and use cases, not as evidence that the client itself works. The advertised properties of the client—such as its class-based interface and test suite—are asserted rather than demonstrated, and the paper does not include a repository URL or installation instructions. That is a verifiability problem, but it is not circularity: an unverifiable existence claim is not the same as a claim whose derivation is equivalent to its own assumptions. No step in the paper defines the client in terms of its own success, fits a parameter and then calls it a prediction, or imports a uniqueness theorem from the authors' prior work. The paper could be improved by linking the actual artifact and showing test coverage, but under the circularity rubric, the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No free parameters or invented entities. The paper's contributions are axiomatic and software-level; its soundness rests on the existence and correctness of the unshown code.

assumptions (3)

domain assumption The ATLAS REST API exists and behaves as described in Smith et al. (2020); the client's utilities correspond to API endpoints.
Summary and Statement of need rely on the server's API without providing endpoint documentation.
domain assumption The client's reported integrations (Mookodi, VRA) actually use the described package.
These are self-reported in the Statement of need; no independent evidence is given.
domain assumption The Python client can be installed and run with standard Python tooling.
No installation instructions are given, so the claim assumes standard package installation works.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A Python client for the ATLAS API." pith.science (2026). https://pith.science/paper/GWB5XYYA

@misc{pith2026250606403,
  author       = {Pith},
  title        = {Pith review of: A Python client for the ATLAS API},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GWB5XYYA}},
  note         = {Machine review of arXiv:2506.06403}
}

read the original abstract

The Asteroid Terrestrial-impact Last Alert System (ATLAS) is an all-sky optical sky survey with a cadence of 24 to 48 hours and the ATLAS Transient Server processes the alert stream to enable the discovery and follow-up of extra-galactic transients. The data from the ATLAS server can be accessed through a REST API, which has allowed the development of bots that need direct access to the data to help rank alerts and trigger followup observations of promising targets. Here we present the python client we have developed for the ATLAS API to help connect bots and scientists to our data.

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

The ATLAS Virtual Research Assistant
astro-ph.IM 2025-06 conditional novelty 6.0 of 10

A gradient-boosted tree pair scoring alerts as real and extragalactic reduces ATLAS eyeballing workload by 85% with a measured potential follow-up loss below 0.08%.

Reference graph

Works this paper leans on

7 extracted references · 3 canonical work pages · cited by 1 Pith paper

[1]

Erasmus, N., Cunnama, D., Potter, S., & Stevance, H. (2025). SAAO IO Transient Classification Report for 2025-02-04 . Transient Name Server Classification Report, 2025-485, 1

work page 2025
[2]

B., van Gend, C

Erasmus, Nicolas, Potter, S. B., van Gend, C. H. D. R., Loubser, E., Rosie, K., Titus, K., Chandra, S., Worters, H. L., Gajjar, H., Hlakola, M., & Julie, R. (2024). Instrumentation at the SAAO for autonomous rapid-response observing . In J. J. Bryant, K. Motohara, & Joël. R. D. Vernet (Eds.), Ground-based and airborne instrumentation for astronomy x (Vol....

doi:10.1117/12.3015250 2024
[3]

Heloise, & genghisken. (2025). HeloiseS/atlasvras: VRA 1.1 (Version v1.1). Zenodo. https://doi.org/10.5281/zenodo.14983116

work page doi:10.5281/zenodo.14983116 2025
[4]

Radhakrishnan Santhakumari, K. K., Battaini, F., Di Filippo, S., Di Rosa, S., Cabona, L., Claudi, R., Lessio, L., Dima, M., Young, D., Landoni, M., Colapietro, M., D'Orsi, S., Aliverti, M., Genoni, M., Munari, M., Zanmar Sanchez, R., Vitali, F., Ricci, D., Schipani, P., Stritzinger, M. (2024). What is your favorite transient event? SOXS is almost ready to...

arXiv doi:10.48550/arxiv.2407.17288 2024
[5]

W., Smartt, S

Smith, K. W., Smartt, S. J., Young, D. R., Tonry, J. L., Denneau, L., Flewelling, H., Heinze, A. N., Weiland, H. J., Stalder, B., Rest, A., Stubbs, C. W., Anderson, J. P., Chen, T.-W., Clark, P., Do, A., Förster, F., Fulton, M., Gillanders, J., McBrien, O. R., Wright, D. E. (2020). Design and Operation of the ATLAS Transient Science Server . 132(1014), 08...

doi:10.1088/1538-3873/ab936e 2020
[6]

L., Denneau, L., Heinze, A

Tonry, J. L., Denneau, L., Heinze, A. N., Stalder, B., Smith, K. W., Smartt, S. J., Stubbs, C. W., Weiland, H. J., & Rest, A. (2018). ATLAS: A High-cadence All-sky Survey System . 130(988), 064505. https://doi.org/10.1088/1538-3873/aabadf

doi:10.1088/1538-3873/aabadf 2018
[7]

Wet, S. D. (2025). BlackGEM Transient Classification Report for 2025-01-06 . Transient Name Server Classification Report, 2025-80, 1. CSLReferences document

work page 2025

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Erasmus, N., Cunnama, D., Potter, S., & Stevance, H. (2025). SAAO IO Transient Classification Report for 2025-02-04 . Transient Name Server Classification Report, 2025-485, 1

work page 2025

[2] [2]

B., van Gend, C

Erasmus, Nicolas, Potter, S. B., van Gend, C. H. D. R., Loubser, E., Rosie, K., Titus, K., Chandra, S., Worters, H. L., Gajjar, H., Hlakola, M., & Julie, R. (2024). Instrumentation at the SAAO for autonomous rapid-response observing . In J. J. Bryant, K. Motohara, & Joël. R. D. Vernet (Eds.), Ground-based and airborne instrumentation for astronomy x (Vol....

doi:10.1117/12.3015250 2024

[3] [3]

Heloise, & genghisken. (2025). HeloiseS/atlasvras: VRA 1.1 (Version v1.1). Zenodo. https://doi.org/10.5281/zenodo.14983116

work page doi:10.5281/zenodo.14983116 2025

[4] [4]

Radhakrishnan Santhakumari, K. K., Battaini, F., Di Filippo, S., Di Rosa, S., Cabona, L., Claudi, R., Lessio, L., Dima, M., Young, D., Landoni, M., Colapietro, M., D'Orsi, S., Aliverti, M., Genoni, M., Munari, M., Zanmar Sanchez, R., Vitali, F., Ricci, D., Schipani, P., Stritzinger, M. (2024). What is your favorite transient event? SOXS is almost ready to...

arXiv doi:10.48550/arxiv.2407.17288 2024

[5] [5]

W., Smartt, S

Smith, K. W., Smartt, S. J., Young, D. R., Tonry, J. L., Denneau, L., Flewelling, H., Heinze, A. N., Weiland, H. J., Stalder, B., Rest, A., Stubbs, C. W., Anderson, J. P., Chen, T.-W., Clark, P., Do, A., Förster, F., Fulton, M., Gillanders, J., McBrien, O. R., Wright, D. E. (2020). Design and Operation of the ATLAS Transient Science Server . 132(1014), 08...

doi:10.1088/1538-3873/ab936e 2020

[6] [6]

L., Denneau, L., Heinze, A

Tonry, J. L., Denneau, L., Heinze, A. N., Stalder, B., Smith, K. W., Smartt, S. J., Stubbs, C. W., Weiland, H. J., & Rest, A. (2018). ATLAS: A High-cadence All-sky Survey System . 130(988), 064505. https://doi.org/10.1088/1538-3873/aabadf

doi:10.1088/1538-3873/aabadf 2018

[7] [7]

Wet, S. D. (2025). BlackGEM Transient Classification Report for 2025-01-06 . Transient Name Server Classification Report, 2025-80, 1. CSLReferences document

work page 2025