Report vs Alert in REST API for saved searches

[catchaj88]

I queried the /servicesNS/-/-/saved/searches GET API and got a number of responses which included saved searches listed under Reports and Alerts on the front end. I took the response for one of the alerts, extracted the relevant information (without changing any values) and did a POST to /servicesNS/{owner}/{app}/saved/searches/{name}. After I did the POST, the saved search is now showing up under Report on the UI.

[AVOLLMER]

I used this to determine if the saved search was a report or an alert:
| eval ss_type=if((NOT 'action'=="*" AND NOT alert_track=="*" AND NOT alert_condition=="*" AND 'alert_type'=="always"),"report","alert")
it may just be when 'alert_type'=="always" but I added the others to be safe. I needed to do this to create clickable links that would open the report or alert . So you might want to check if it has these values, which would cause it to be recognized as a report.

[danielbb]

It's an old thread, but is alert_type=="always" enough to determine that a saved search is an alert?

[danielbb]

Apparently, it's the other way around - alert_type == "always", means that the saved search is a report, because it always fires and therefore to detect alerts we need to use alert_type != "always", in cases when alert_type == "number of events" etc.

[emottola]

The thread is even older now, but I also found you need to specify  `'alert.suppress': 0` when posting to `/servicesNS/{owner}/{app}/saved/searches/` to make sure it's an alert and not a report.
In total, I specified at least the below parameters to create an alert

{
    'is_scheduled': 1,
    'cron_schedule': '09-59/10 * * * *',
    'alert_comparator': 'greater than',
    'alert_threshold': 5,
    'alert_type': 'number of events',
    'alert.suppress': 0,
}