The following values are utilized in Catchpoint’s REST API and Alerts Webhook to filter tests by their test and monitor type IDs with their corresponding test and monitor names.
Test Type Values:
${DisplayTestTypeId}
Gives the Display Test Type id as below:
| Test Type | Type ID |
| Web | 0 |
| Transaction | 1 |
| HTML Code | 2 |
| FTP | 3 |
| TCP | 4 |
| DNS | 5 |
| Ping | 6 |
| SMTP | 7 |
| UDP | 8 |
| API | 9 |
| Streaming | 10 |
| SSH | 11 |
| Traceroute | 12 |
| WebSocket | 13 |
| NTP | 14 |
| IMAP | 15 |
| MQTT | 16 |
| Bulk | 17 |
| SSL | 18 |
| WIFI | 19 |
| BGP | 20 |
The monitor type determines exactly how a test is executed. Certain test types have multiple monitors available, such as Web tests which have Object, Emulated, Mobile, and Chrome. Other test types have only one monitor; for example FTP tests have only FTP. Some monitors may not be visible in the Catchpoint interface.
| Monitor Type | Monitor ID |
|---|---|
| IE Browser | 0 |
| Object | 2 |
| Emulated | 3 |
| MQTT | 5 |
| IMAP | 6 |
| NTP | 7 |
| Ping (ICMP) | 8 |
| Tracert (ICMP) | 9 |
| DNS (Traversal) | 10 |
| Ping (TCP) | 11 |
| DNS (EXP) | 12 |
| DNS (Direct) | 13 |
| Tracert (UDP) | 14 |
| Port (TCP) | 15 |
| FTP | 16 |
| API real time (webhook failure) | 17 |
| Chrome | 18 |
| Playback | 19 |
| Playback (Mobile) | 20 |
| SMTP | 21 |
| Port (UDP) | 22 |
| Ping (UDP) | 23 |
| Streaming | 24 |
| API | 25 |
| Mobile | 26 |
| SFTP | 27 |
| SSH | 28 |
| Tracert (TCP) | 29 |
| WebSocket | 30 |
| ## |
| Synthetic-Node-SSL | 31 |
| Synthetic-Node-WiFi | 32 |
| Synthetic-Node-Shell-Script | 33 |
| Synthetic-Node-Bgp | 34 |
Simulator type and IDs
| Simulator Type | Simulator Type ID |
| Android | 3 |
| iPhone | 4 |
| IPad | 5 |
| KindleFire | 6 |
| GalaxyTab | 7 |
| IPhone5 | 8 |
| IPadMini | 9 |
| GalaxyNote | 10 |
| Nexus7 | 11 |
| Nexus4 | 12 |
| NokiaLumia920 | 13 |
| IPhone6 | 14 |
| BlackBerryZ30 | 15 |
| GalaxyS4 | 16 |
| HTCOneX | 17 |
| LGOptimusG | 18 |
| DroidRazrHD | 19 |
| Nexus6 | 20 |
| IPhone6s | 21 |
| GalaxyS6 | 22 |
| IPhone7 | 23 |
| Google Pixel | 24 |
| GalaxyS8 | 25 |
Usage & Examples:
When using the REST API, the GET request here:
...with the {testId} and {monitorId} macros can be used to filter and retrieve tests by test and monitor types. The below example will pull all DNS tests within the client level:
api/v1/tests?testId={5}
We can also get the active and inactive test's information using "statusId" parameter in the REST API URI. The value could be 0, 1 or -1 for "statusId" parameter.
statusId=0 will pull all the active test information from a specific account, division, or folder.
statusId=1 will pull all inactive test information from a specific account, division, or folder.
statusId=-1 will give you both active and inactive test's information.
Example URI
GET api/v{version}/tests?divisionId={divisionId}&productId={productId}&parentFolderId={parentFolderId}&statusId={statusId}
When using the Alerts Webhook, the ${MonitorTypeId} macros can be used with a ${switch} macro to report the monitor names instead of the ID values. Examples of setting up the MonitorType macros in a template can be found below:
MonitorType: ${switch(${MonitorTypeId},'0','IE Browser','2','Object','3','Emulated')}
This XML (https://docs.catchpoint.com/docs/alert-webhook-xml-result) and JSON (https://docs.catchpoint.com/docs/Alert-Webhook-JSON-Result) examples demonstrate what the results look like when using the macros without a ${switch} macro in the XML and JSON files.
Note: The Status field seen in the Alerts Rest API call is different from the StatusID shown above. In the case of Alerts API: GET /api/v{version}/alerts, The Status field is optional and it represents the Incidents state.
| Status | Status ID |
| 5 | Incident Open |
| 6 | Incident Resolved |
Please reach out to Catchpoint Support (support@catchpoint.com) if you have any queries.