TNS Newsfeed

Here we will notify about new features, modifications, open issues, and any general news and remarks...


We are glad to announce a new feature we have deployed, to enable easier and quicker mass download of information about TNS public objects.
Staging the CSV files will fulfil requests by TNS users, as well as encourage performing time-consuming operations locally by users, reducing the load on the TNS servers.
For example, if you need to cross-match entire catalogs or long object lists, we request that this would be done locally, against the csv (or a locally managed DB), rather than by executing multiple cone-searches via the Search API.
Calling the APIs for a limited number of objects is clearly fine, but we ask that our users apply appropriate caution and sensibility when using the TNS resources, that serve a broad community.
Every day after UT midnight, two CSV files are created and are accessible for download under:
1. - holds the entire catalog of TNS public objects (AT/SN/FRB/... ~70,000 currently). This file is overwritten daily.
The date and time when the list of objects was created is specified in the first line; e.g. "2021-03-15 00:00:00"
2. - holds only those entries (objects) that were either added or modified during the specified day.
So, e.g. during Mar 15, 2021 it is possible to download this latest CSV for the previous day:
The first line in the CSV will contain the exact duration covering the entries in the file; e.g. for the above example: "2021-03-14 00:00:00 - 23:59:59"
The separate daily files remain in place for 1 month backwards.


The csv's contain the following columns:


cURL usage examples for downloading (note that the api-key is required):

curl -X POST -d 'api_key=YOUR-API-KEY' >
curl -X POST -d 'api_key=YOUR-API-KEY' >

Please do let us know if any major properties are missing or if you have any questions.


As the use of the AstroNotes is growing, we've added a new AstroNotes Stats page, displaying the released AstroNotes timeline and break down of the reporting groups when hovering on the data points.

You may find this useful, similar to the Discovery and Classification Reports Timeline as shown on the general TNS statistics page.

Note that besides specification of a date range and Daily/Monthly/Yearly visualization, it is possible to filter by the type of AstroNote - whether Object-discovery/classification, Object-data analysis, Announcement-Tool/Utility etc... 

Feedbacks and comments are as always most welcome.



We're glad to update that the TNS has been migrated to the AWS cloud platform today, Sun Dec 27, 2020.

Having the TNS deployed in this environment will improve the high-availability and scalability of the system, across multiple servers and availability zones, as preparation for future increased activity.

Redirects will be in place during the coming several weeks, but do make sure to update by the end of January 2021 the TNS URLs in your links and scripts as follows:

Real site:

The APIs handbooks and sample codes (accesible from the help page) have been revised with the updated entries.

No additional changes are required; all data, including account credentials, group definitions etc have been migrated as they are.

We hope that everything will continue to run flawlessly and we'll appreciate if you notify us on any issues if encountered via the contact page.

The TNS team.


As part of implementing some improvements to the Search & Get (object details) APIs, the following changes were deployed on the Sandbox environment, and they are due to be deployed on the real site on Mon, Aug 17.

*** The changes involve deletion of a few keywords, listed below, so please make sure to arrange your scripts so that they will not fail. ***

  • The following 5 keywords were removed from the reply JSON of the Get API:
    • name ("objname" remains in place instead, displaying the object name)
    • isTNS_AT (not needed; an indication if the object was reported to the TNS or if it is a "historical" one, ingested to the TNS.)
    • sourceid -> changed to "source", displaying if the discovery report was sent by a "bot" or a "user"
    • discovererid -> changed to "reporterid" - displaying the id of the bot or user who submitted the discovery report.
    • internal_name -> changed to "discoverer_internal_name". ("internal_names" (in plural) remains as is, showing all the internal_names reported for the object).
  • An "objid" (the unique id of the object on the TNS) entry was added to the reply JSONs of both the Search & Get APIs; and also as a query parameter in the input JSONs of both APIs.
  • The order of the resulting keywords was also arranged; not affecting the scripts, but so that it would be more convinient also for humans to review the retrieved entries/properties.
  • The reply JSON for the Get API now looks like this (e.g. for 2020qdo):

    "reply": {
      "objname": "2020qdo",
      "name_prefix": "SN",
      "objid": 64211,
      "object_type": {
        "name": "SN Ia",
        "id": 3
      "redshift": 0.011,
      "ra": "02:09:12.776",
      "dec": "+18:55:55.35",
      "radeg": 32.3032316667,
      "decdeg": 18.9320416667,
      "hostname": null,
      "host_redshift": null,
      "internal_names": "ATLAS20ugw",
      "discoverer_internal_name": "ATLAS20ugw",
      "discoverydate": "2020-07-23 13:35:02.400",
      "discoverer": "J. Tonry, L. Denneau, A. Heinze, H. Weiland, H. Flewelling (IfA, University of Hawaii), B. Stalder (LSST), A. Rest (STScI), C. Stubbs (Harvard University), K. W. Smith, S. J. Smartt, D. R. Young, S. Srivastav, O. McBrien, D. O'Neill, P. Clark, M. Fulton, J. Gillanders, M. Dobson (Queen's University Belfast), T.-W. Chen (MPE), D. E. Wright (University of Minnesota), J. Anderson (ESO), A. Townsend (University of Manchester)",
      "reporter": "ATLAS_Bot1",
      "reporterid": 35595,
      "source": "bot",
      "discoverymag": 19.038,
      "discmagfilter": {
        "id": 72,
        "name": "orange",
        "family": "ATLAS"
      "reporting_group": {
        "groupid": 18,
        "group_name": "ATLAS"
      "discovery_data_source": {
        "groupid": 18,
        "group_name": "ATLAS"
      "public": 1,
      "end_prop_period": null

followed by the photometry/spectra data if requested...


  • As mentioned, the new API JSONs will come into effect on the real site on Aug 17; it is possible to experiment with the new format against the Sandbox, also here on the API TEST FORM.


Comments and feedbacks are clearly welcome.


Kind regards,

The TNS Team.



Following requests from the community, we now index (create official ADS bibcode for) all classification reports submitted to the TNS, not only for the "formal classifier" (the first classification made public).

This is useful especially for those cases where the first classification is later realized to be incorrect/uncertain, or either there is a true dilemma about the nature of an event, and it is necessary to be able to officially cite other reported classifications.

The bibcode for all classifications of an object is now shown in the last column (ADS Bibcode) of the Classification Reports sub-table on the Search/Object pages, linking to the ADS.

(For the formal classification report, the ADS bibcode also appears on the "Classification Certificate", as before.)

We've also created and updated on the ADS the indexes for all relevant past classification reports, from 2016 until now. All backlog ADS indexes can be reviewed here.

Do let us know if you encounter anything suspicious or if an entry you're looking for is missing. 


As of March 2020 the TNS serves as the official name server and hub for distribution of FRB events. At the request of this community, the TNS now operates two engines for designation of names, the original 'YYYYabc' (currently serving AT/SN), and now also 'YYYYMMDDabc' for FRBs (and potential future communities requiring such a format). New pages and processes have been deployed, enabling the reporting, distribution and querying of FRB events using both interactive forms and APIs.

Please see AstroNote 2020-70 for additional details on the major newly added components and functionalities.


In order to adapt the TNS for both the present and future needs, and in particular to the activity of transient brokers as significant sources that report discoveries of transients that are observed and publicly released by the observing surveys/facilities, we have deployed today - Dec 1st, 2019 - the adjustments to the handling of the “discovery group/s”, by introducing instead two distinct group identifications: the Reporting group and the Discovery Data Source group.

The changes affect the AT Report JSON/TSV formats (and clearly the AT Report Form), the search page, the object page, the discovery certificate and the statistics pages.

Please refer to AstroNote 2019-136 for additional clarifications on the essence of the revised treatments.

As mentioned, even if you did not revise your JSONs to the new format, your AT reports should not fail until Jan 31st, 2020.

However, if sending AT Reports via TSV, you should have the correct revised columns in place (reporting_group_id, discovery_data_source_id - instead of the single groupid).



On the Search API, it is now possible to explicitly specify if we require exact matches or LIKE '...%' for both the objname and internal_name.

The default values are "0" - for non-exact matches. Note that any specified prefix (AT/SN...) is ignored, and we relate to only the unique objname.

  "ra": "",
  "dec": "",
  "radius": "",
  "units": "",
  "objname": "",
  "objname_exact_match": 0,
  "internal_name": "",
  "internal_name_exact_match": 0,
  "public_timestamp": ""

For the Get API, the reply now includes a new internal_names entry that lists (csv) all existing internal names of the object, where the first internal_name is that of the official discovery report.

The existing internal_name entry remains as is for backward compatability.

So, e.g., for 2018ibb, we get the following entries:

      "internal_name": "ATLAS18unu",
      "internal_names": "ATLAS18unu, ZTF18acenqto, PS19crg, Gaia19cvo",



We deployed today GUI improvements, also w.r.t. mobile behaviour, on the following pages:

  • AT / Classification Report Forms
  • Search page
  • AstroNotes main page
  • Add AstroNote form

We'll appreciate to receive feedback if any additional revisions/improvements are required.



When creating a new AstroNote (Add AstroNote), it is now possible to assign up to 3 additional editors (registered TNS users), who will also be able to edit the draft AstroNote, besides the person who created the AstroNote.

This is especially useful when an AstroNote is submitted on behalf of a survey/group, and whenever its relevant for additional people to be able to update and release the Note.

The specification of the additional editors is not done on the level of a template definition but when adding (creating) a new AstroNote.

The editors fields are auto-complete on the first/last names.