Catchpoint’s API Test enables scheduled monitoring of API performance and availability by executing pre-configured HTTP requests and validating the responses. It supports a wide range of HTTP methods (GET, POST, PUT, DELETE) and allows for custom headers, payloads, and authentication schemes. You can define assertions on response codes, body content, and headers.
It supports multi-step workflows to simulate chained API calls and allows for detailed validation of both JSON and XML response headers and bodies, ensuring functional accuracy and performance consistency across endpoints.
Start scripting using JavaScript API script guide.
API Test Use Cases
Availability & Performance Monitoring: Continuously Monitor first- and third-party APIs to ensure they are reachable and responsive from global locations.
Token Expiry & Auth Flow Validation: Automatically test authentication flows (e.g., OAuth token refresh) to ensure secure and uninterrupted access.
Multi-Step API Workflows: Simulate chained API calls to test complex workflows such as authentication followed by data retrieval or submission.
Mobile App API Monitoring: Validate the performance, availability, and correctness of backend APIs powering mobile apps by simulating real-world requests from distributed locations.
Alerting & Incident Response: Configure monitors to trigger alerts (via email, Slack, or webhook) when failures or anomalies are detected.
Custom Metrics: Capture values like server name serving the request to tailor monitoring to your app’s unique behavior.
SLO/SLA Compliance Monitoring: Track service-level objectives by defining performance and availability thresholds, and automatically measure compliance over time.
API-as-a-Product SLA Enforcement: For APIs offered to external consumers, monitor uptime and performance to ensure SLA compliance and maintain customer trust.
API Test Results
The Records page for API Test displays the monitored API endpoint along with the corresponding request and response headers.
API Test Configurations
Below are the different test settings, advanced settings and metrics supported by API test.
API Test Properties |
|
|---|---|
| Name | A name used to identify this test. |
| Description | Optional additional information about the test |
| Label | Optional Label to assign to this test. (learn more about labels.) |
| Script (dropdown menu) | The scripting language used to create the test API call. (Selenium or Javascript) |
| Script (text field) | The API call script. For information on API Test scripting, read the API Test Scripting Guide. |
| Location | The Product/Folder location of this test (read only) |
| Status | Determines whether this test is current Active or Inactive |
API Test Advanced Settings | |
|---|---|
| 30x Redirects Do Not Follow | By enabling this, it will disable the redirect in the Primary URL. While Monitoring only with respect to Primary URL, this option is useful to avoid redirects. |
| 40x or 50x Mark Successful | Allows the agent to not treat 40x and 50x response code as failures. The Playwright test will continue executing the next line of code ignoring this error. |
| Additional Monitor | Runs an additional Traceroute or Ping test again from the same node to the destination. |
| Debug Primary Host on Failure | Runs Ping, Traceroute, and DNS traversal to the primary host on test failure. By default, it runs DNS Traversal in case of DNS failure or in the case a DNS Alert Threshold is breached. It will run Ping and Traceroutes in case of Connect, Wait, Load, or Response failure or in the case the respective alert thresholds are breached. The Ping and Traceroute will also run in the case a Webpage Response or Webpage Response with Suspect Alert Threshold is breached - and the main URL response was 20% or higher than Webpage Response. |
| Debug Referenced Host on Failure | Runs Ping, Traceroute, and DNS traversal to the referenced hosts on test failure. |
| Enable MTU Path Discovery | Enables collection of Traceroute Path MTU data. Applies only if additional monitor with traceroute is enabled. |
| Enforce Failure if test runs longer than | Causes test to result in failure if it runs longer than the specified time. For Playwright he default threshold is 30 seconds per step. Allwed on Backbone and Enterprise nodes only. |
| Host Data | Captures metrics on a per-host basis. |
| Http Headers Capture | If enabled, collects HTTP request/response header information. You can specify if the capture should happen: On Test Failure - when the test fails. On Any Failure - if the test or any request fails or there are JavaScript errors. Always - every time the test runs. The data is available in the waterfall charts. This feature is not required for insights, the two are independent of each other. It does not cost additional points. |
| HTTP Version | If enabled, allows to run Object and API tests on the selected HTTP version. (Default is HTTP/1.n). |
| Response Content or Metadata Capture | Collects HTTP response content and metadata. |
| SSL Errors Ignored | Force the agent to ignore SSL errors. This can be useful when the SSL certificate on the host does not match the domain. By default, any SSL failures will cause the test to stop and fail. |
| Test Size Override Enabled | When enabled, test runs/steps will be allowed to exceed the default limit up to an absolute maximum of 30 MB for backbone and last-mile nodes, or 15 MB for wireless. This will impact point usage. |
| Third Party Zone | Classifies any data not matching the Self Zone as Third Party. |
| Tracing | Collects server-side telemetry for end-to-end visibility. |
| Verify Test on Failure | Runs the test again from the same node in the event of failure. However, will not run the test again when the test receives an HTTP 4xx or 5xx status code. Also, will not run the test again when Test Failure : [50061] - HTTP response header (root-request) did not satisfy the alert settings. If a second test to verify a failure does run, then additional points will be consumed, which match the type of test and any other advanced settings that are enabled. The first failed test run will appear on the waterfall with an "This was the first test for the interval, which failed and was repeated.” However, it will not be included in performance charts, reports, or alerts. The second test run, that ran to verify the failure, will always be included in performance charts, reports, and alerts. |
| Zone Data | Captures metrics for defined Zones (hostnames, paths, URLs, or IPs). |
API Test Supported Metrics | |
|---|---|
| # Connections | The total number of TCP connections established during the test. |
| # DNS Failures | The number of times the system was unable to resolve the domain from the endpoint to an IP address. |
| # Purged Runs | The number of test runs manually excluded from calculation for purposes of SLA accuracy. |
| # Runs | Total number of test runs for the defined time period. |
| % Adjusted Availability | Ignoring any purged runs, the percentage of test runs where the enpoint was reached and the test was completed (i.e. there was not a Test Error.) |
| % Availability | The percentage of test runs where the endpoint was reached and the test was completed (i.e. there was not a Test Error.) Availability is calculated as: (# Test Runs - # Test Errors) / # Test Runs |
| % Downtime | The percentage of test runs where the endpoint was unavailable, unreachable, or otherwise failed.) Downtime is calculated as: # Failures / # Test Runs |
| % Frustrated | The percentage of test runs that exceeded the Apdex “frustrated” threshold. |
| % Not Frustrated | The percentage of test runs that completed in less time than the Apdex “frustrated” threshold. This is equivalent to: % Satisfied + % Tolerating |
| % Satisfied | The percentage of test runs that completed in less time than the Apdex “Satisfied” threshold. |
| % Tolerating | The percentage of test runs that exceeded the Apdex “Satisfied” threshold but completed in less time than the “Frustrated” threshold. |
| Apdex | A scoring mechanism that translates performance metrics of diverse applications into generic “User Satisfaction” levels using predefined response time thresholds. You can use default Apdex thresholds or configure your own on a per basis. For more details about Apdex, visit http://www.apdex.org/ |
| Connect (ms) | The time it took to establish a TCP connection with the server. |
| DNS (ms) | The time it took to resolve the domain name to an IP address. |
| Downloaded Bytes | The total number of downloaded bytes from the endpoint. |
| Experience Score | A composite metric that captures the overall experience of a user on a scale of 0-100. |
| Response (ms) | The total time from the initial request until receiving the last packet of response data. |
| Server Response (ms) | The time from when DNS was resolved to receiving the last response packet from server. (This shows the server response exclusive of DNS times) |
| SSL (ms) | The time it took to complete the ssl handshake with the server. |
| Test Time (ms) | One cohesive metric that applies to all test types and indicates the total duration of the test run. Test Time is equivalent to Response, Test Response (Transaction and web tests) and ping RTT (Trace Route tests), and is used when calculating Apdex. Test Time is not available for Request, Host, or Zone charting. |
| Throughput | Measures how efficiently the system was able to retrieve all elements in kilobytes per second. Throughput is calculated as follows: Throughput = Size / Timewhere: Size = (FileSize + HeaderSize)/1024 *converts from bytes to KBs Time = (Wait + Load)/1000 *converts from ms to seconds |
| Time To First Byte (ms) | The total time from the initial DNS request to receiving the first response packet from the server. This is calculated as: |
| Total Downloaded Bytes | The total number of downloaded bytes. |
| Wait (ms) | The time from when the request was sent to the server until the first response packet was received. (Known as "First Byte" in some tools) |