API Health Check - Apinizer Dokümantasyonu

Overview

24/7 Monitoring

Continuously monitor the availability of your APIs

Performance Metrics

Track response times and success rates

Early Warning

Detect problems before users are affected

Automatic Notifications

Receive instant notifications for quick intervention

API Health Check settings form - All configuration fields

What is API Health Check?

Basic Concept

API Health Check is a monitoring system that automatically sends test requests at specified intervals to an API endpoint or web service you specify.

When to Use?

Critical API Monitoring

Continuous monitoring of critical APIs such as payment and authentication

SLA Tracking

Tracking and reporting of service level agreements

Performance Monitoring

Monitoring API response times and trend analysis

Uptime Monitoring

Tracking service uptime

How Does It Work?

Configuration

URL to be checked, HTTP method, expectations, and scheduling are determined

Scheduling

Test requests are automatically sent at specified times (e.g., every 5 minutes)

Test Execution

HTTP request is sent and response is received

Validation

Expectations (assertions) are checked:

Response time check
HTTP status code check
Response content check
XPath/JSONPath checks

Result Recording

Test result is recorded (successful/failed)

Notification

If the test fails, configured notifications are triggered

Quick Start

Creating Your First Health Check

Access from Menu

Click Main Menu → Monitoring → API Health Check

Create New Check

Click the “Create New” button

Fill in Basic Information

Name: A name for your check (e.g., “Payment API Check”)
Description: Optional description

Enter Request Information

HTTP Method: GET, POST, etc.
URL: API endpoint to be tested

Set Scheduling

Determine check frequency (e.g., Every 5 minutes)

Save

Click the “Save” button

Creating New Health Check

Step 1: Basic Information

Name - Required

Enter a unique name for the health check. This name:

Must be unique within the project
Cannot start with a space
System automatically checks the availability of the name

Good Name Examples:

Payment API Monitoring
User Service Health Check
Third-Party Integration Check
Homepage Availability Check

Description - Optional

You can enter descriptive information about the health check:

Maximum 1000 characters
Used to explain the purpose and scope of the check
Displayed on the list page

Example Descriptions:

Created for 24/7 monitoring of critical payment API
Customer portal homepage availability check
Third-party service provider integration monitoring

Status - Default: Active

Determines the active/passive status of the health check:

Active: Check runs, scheduled tests are sent
Passive: Check is stopped, no tests are sent (historical data is preserved)

Step 2: Scheduling Settings

Determine how frequently the health check will run. Scheduling is done using Cron Expression.

Common Scheduling Examples

Description	Cron Expression	Use Case
Every 5 minutes	`0 /5 ? * *`	For critical APIs (most common)
Every 15 minutes	`0 /15 ? * *`	For normal APIs
Every hour	`0 0 * ? * *`	For Test/Development environments
Every day at 09:00	`0 0 9 * ? *`	For daily reporting
Every Monday at 09:00	`0 0 9 ? * MON`	For weekly checks

Recommendations:

Critical APIs: Every 5 minutes
Normal APIs: Every 15-30 minutes
Test/Development: Every hour
Reporting purposes: Daily or weekly

Step 3: Request Settings

In this section, you configure the information of the endpoint to be tested.

Select From Collection - Recommended

You can use test scenarios you previously created in Test Console:

Click Button

Click the “Select From Collection” button

Select Collection

View your test collections in the opened dialog

Select Scenario

Select the test scenario you want

Auto-Fill

Test information automatically fills the form

Advantages:

You save time
You use consistent test scenarios
You can manage your test scenarios centrally

HTTP Method - Required

Select HTTP request method:

GET

Data reading (most commonly used)

POST

Data sending

PUT

Data updating

DELETE

Data deletion

PATCH

Partial update

HEAD

Header information only

URL - Required

Enter the full URL of the endpoint to be tested:Examples:

https://api.example.com/users
https://api.example.com/payment/verify
http://localhost:8080/health
https://api.example.com/v1/products?category=electronics

Notes:

URL must be absolute
HTTPS and HTTP are supported
Query parameters can be added to URL or specified in a separate field

Parameters - Optional

Used to add query parameters to URL:Example:

Parameter Name: userId
Parameter Value: 12345

Result URL: https://api.example.com/users?userId=12345

Headers - Optional

Used to add headers to HTTP request:Common Uses:

Authorization: Bearer token123 or Basic base64encoded
Content-Type: application/json, application/xml
X-API-Key: your-api-key
Custom Headers: Custom headers

Example:

Header Name: Authorization
Header Value: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Body - For POST/PUT/PATCH

You can enter request body:Supported Formats:

Raw: JSON, XML, Text
Form URL Encoded: Form data

JSON Example:

{
    "userId": 12345,
    "action": "verify",
    "timestamp": "2024-01-15T10:30:00Z"
}

XML Example:

<request>
    <userId>12345</userId>
    <action>verify</action>
</request>

Step 4: Validation Settings

Validation (Assertion) settings determine the checks required for the test result to be considered successful.

Timeout Check (Timeout Assertion)

When this option is activated, the specified timeout value is also used for validation:

Request must be responded to within the specified time
Otherwise test is considered failed

HTTP Status Code Check (Status Code Assertion)

To perform HTTP status code check:

Activate Toggle

Activate the “Result Status Code” toggle

Enter Status Code

Enter the expected status code in the “Expected Status Code” field

Default Value: 200 (OK)Common Status Codes:

200: Successful
201: Created
204: No Content
400: Bad Request
401: Unauthorized
404: Not Found
500: Server Error

Example Scenario:

Expected Status Code: 200
Actual Status Code: 200 → ✅ Successful
Actual Status Code: 500 → ❌ Failed

Response Body Check (Body Assertion)

Checks whether the response body contains specific content:

Activate Toggle

Activate the “Result Body” toggle

Enter Content

Enter the expected content in the “Expected Result Body” field

Use Cases:

Response should contain specific text: "status": "success"
Response should contain specific value: "active": true
Response should not be empty

Example:

Expected: "status": "ok"
Actual: {"status": "ok", "data": {...}} → ✅ Successful
Actual: {"status": "error"} → ❌ Failed

XPath Check (XPath Assertion) - For XML

Performs check using XPath in XML responses:

Activate Toggle

Activate the “XPath Result” toggle

Enter XPath

Enter the XPath expression in the XPath field

Enter Expected Value

Enter the expected value in the Expected XPath Result field

Example:

XPath: /response/status
Expected Result: success
Actual XML: <response><status>success</status></response> → ✅ Successful

JSONPath Check (JSONPath Assertion) - For JSON

Performs check using JSONPath in JSON responses:

Activate Toggle

Activate the “JsonPath Result” toggle

Enter JSONPath

Enter the JSONPath expression in the JsonPath field

Enter Expected Value

Enter the expected value in the Expected JsonPath Result field

Example:

JSONPath: $.status
Expected Result: ok
Actual JSON: {"status": "ok", "data": {...}} → ✅ Successful

Common JSONPath Examples:

$.status: Status field at root
$.data.items[0].id: ID of first item
$.user.name: Name field of user object
$.results[*].id: IDs of all results

Step 5: Settings

Timeout - Default: 30 seconds

Determines the maximum wait time for the request:

Entered in seconds
Default value: 30 seconds
If no response is received within this time, test is considered failed

Recommendations:

For fast APIs: 10-15 seconds
For normal APIs: 30 seconds
For slow APIs: 60 seconds or more

SSL Certificate (Enable Certificate)

To use SSL certificate for HTTPS requests:

When this option is activated, custom SSL certificate can be used
Generally used for self-signed certificates or custom CA certificates

Step 6: Retry Settings

To automatically retry in case of temporary issues:

Retry On Fail

Activate Toggle

Activate the “Retry On Fail” toggle

Select Number

Select “Retry Count”: 1, 3, 5, or 10

How It Works:

If the first request fails
Retries are made up to the specified number
Wait can be made between each attempt (optional)

Example Scenario:

Retry Count: 3
First request failed → 1st retry → failed → 2nd retry → failed → 3rd retry → successful → ✅ Successful

Delay Between Requests

To wait between retries:

Activate Toggle

Activate the “Delay Between Requests” toggle

Enter Wait Time

Enter the wait time in seconds in the “Wait” field

Default Value: 3 secondsUse Case:

To reduce server load
To avoid rate limiting
To give time for temporary issues to resolve

Example:

Retry Count: 3
Wait: 5 seconds
First request failed → wait 5 sec → 1st retry → failed → wait 5 sec → 2nd retry → successful

Step 7: Notification Recipients

Configure notifications that will be triggered when the test fails:

Adding Notifications

Add Notification

Click the ”+” button in the Recipients table

Select Notification Type

Select notification type:

Email: Sends email notification
Webhook: Sends HTTP POST request
Slack: Sends message to Slack channel
SMS: Sends SMS notification
And more…

Complete Configuration

Complete the notification configuration

Notification Management:

Edit: Select “Edit” from the menu to update notification information
Delete: Select “Delete” from the menu to remove the notification
Active/Passive: You can activate/deactivate the notification with toggle

Notification Content: The following information is sent in notifications:

Health check name
Proxy name (if any)
Target URL
Error message
Timestamp
Test result details

Step 8: Saving

After filling in all information:

Validation Check

Make sure form validations pass:

✅ Name entered and available
✅ URL entered
✅ Scheduling settings configured
✅ At least one assertion active (recommended)

Save

Click the “Save” button

Redirect

After the health check is saved, you will be automatically redirected to the listing page

Monitoring and Reporting Results

Accessing Results Page

Access from List

Click on the check name in the health check list

Access from Menu

Select “Results” option from the operations menu (⋮)

Results Page Sections

1. Header Section

Date Range Selector: Filter results by a specific date range
Refresh Button: Manually refresh results
HTTP Method and URL: Information about the tested endpoint

2. Status Summary

The general status of the health check is shown at the top of the page:Response Time Graph:

Line graph showing response times over time
X axis: Date/Time
Y axis: Response time (milliseconds)
You can see detailed information by hovering over the graph

Average Response Time:

Average response time of all tests (milliseconds)
Shown in large and bold text
Important metric for performance evaluation

Success Rate:

Ratio of successful tests to total tests (percentage)
Green: Good performance (95%+)
Yellow: Medium performance (80-95%)
Red: Low success rate (below 80%)

Status summary and test results table

3. Test Results Table

Table showing detailed results of each test run:Columns:

Request Sent: Date and time when the test request was sent
Request Type:
Initial Request: Normal test request
Retry: Retry request
Response Time: Response time of the request (milliseconds)
Assertions: Checks performed and their results:
✅ Timeout: Request did not timeout
✅ Status Code: Expected HTTP status code returned
✅ Result Body: Response body validated
✅ XPath: XPath check successful (for XML)
✅ JSONPath: JSONPath check successful (for JSON)
Result:
🟢 Successful: All checks passed
🔴 Failed: At least one check failed
Detail: Eye icon (👁️) to view result details in JSON format

Viewing Result Details

Click Detail Button

Click the eye icon (👁️) button in the table

Review Details

In the opened dialog, you can view all details of the test result in JSON format:

Request information (URL, method, headers, body)
Response information (status code, headers, body)
Assertion results (result of each check)
Error messages (if any)
Timestamps

Deleting All Results

This operation cannot be undone! All historical data will be lost.

Click Delete Button

Click the trash can (🗑️) icon in the table header

Deletion Completed

All results are permanently deleted

Health Check Management

List Page Features

On the health check list page, you can view and manage all your checks.

Search and Filtering

Search by Name: Filter checks by typing in the name field
Search by Description: Search by typing in the description field
Project Filter (Admin mode): View checks from multiple projects
Clear: Click the eraser icon to clear all filters

Table Columns

Name: Health check name (clickable, goes to results page)
Description: Check description
Target URL: URL of the tested endpoint
Status: Active/Passive status (can be changed with toggle)
Project (Admin mode): Project the check belongs to
Operations: Menu button (⋮)

Operations Menu

Changing Status

To change the active/passive status of the check:

Click Toggle

Click the toggle in the Status column in the table

Status Updated

Check status is updated instantly

Passive Checks

Passive checks do not run, but their historical data is preserved

Best Practices

1. Naming Conventions

Use Descriptive Names: Clear names like Payment API Check
Add Project/Module Prefix: Like E-Commerce - Payment API
Add Environment Information: Like Production - User API

2. Scheduling Strategy

Critical APIs: Check every 5 minutes
Normal APIs: Check every 15-30 minutes
Test Environments: Check every hour
Consider server load

3. Assertion Usage

Use at least one assertion (Status Code recommended)
Always activate timeout assertion
Use body assertions carefully (if variable content exists)
Make specific checks using JSONPath/XPath

4. Retry Strategy

Use retry for temporary issues
Keep retry count reasonable (between 3-5)
Reduce server load by using delay
Increase delay in rate limiting situations

5. Notification Management

Use email + SMS notification for critical checks
Send notifications to your integration systems using Webhook
Filter to avoid notification spam
Create notification groups

6. Performance Monitoring

Regularly check response times
Track success rates (aim for 95%+)
Perform trend analysis (examine graphs)
Set threshold values for anomaly detection

Frequently Asked Questions

How Often Does Health Check Run?

The frequency of check execution depends on the Scheduling (Cron Expression) settings you determined when creating it. For example:

0 */5 * ? * * → Every 5 minutes
0 0 * ? * * → Every hour
0 0 9 * ? * → Every day at 09:00

What Happens When Check is Deactivated?

When check is deactivated:

No new test requests are sent
Existing scheduled jobs are cancelled
Historical results are preserved and can be viewed
Check continues normal operation when reactivated

How Does Retry Work?

When “Retry On Fail” feature is activated:

First request is sent
If it fails (any assertion fails)
Retries are made up to the number you specified
If there is wait between requests, wait for the specified duration
If all attempts fail, result is recorded as “Failed”

When Are Notifications Sent?

Notifications (Recipients) are triggered in the following situations:

When test fails
Separate notification is sent for each failed test
Notifications are not sent for successful tests (default behavior)

How Do Assertion Checks Work?

Assertion checks are performed in the following order:

Timeout Check: Was the request responded to within the specified time?
Status Code Check: Does HTTP status code match the expected value?
Body Check: Does response body match the expected content?
XPath Check: Does XPath expression give correct result in XML response?
JSONPath Check: Does JSONPath expression give correct result in JSON response?

Important: All active assertions must be successful. If any one fails, the test result is marked as “Failed”.

What is the Use of Selecting from Test Collection?

The select from test collection feature allows you to reuse test scenarios you previously created in Test Console. This way:

You save time
You use consistent test scenarios
You can manage your test scenarios centrally

What Happens When Check is Deleted?

When check is deleted:

Check definition is deleted from database
All test results are deleted
Scheduled jobs are cancelled
Historical data is permanently lost

Deletion cannot be undone!

How Long Are Results Kept?

Results are kept until manually deleted. To clean old results:

You can use the “Delete All Results” button on the results page
Or you can clean results regularly

Can I Use Multiple Assertions?

Yes, you can use multiple assertions. All active assertions must be successful. For example:

Status Code: 200 ✅
“success” text in Body ✅
JSONPath: $.status = “ok” ✅

If all are successful, test is considered successful.

Can I Use Dynamic Parameters in URL?

No, dynamic parameters cannot be used in URL. However:

You can add query parameters
You can use dynamic values in headers (in some cases)
You can use dynamic content in body

Troubleshooting

Check Not Working

Possible Causes:

Check may be in passive status → Check status toggle
Scheduling settings may be wrong → Check cron expression
URL may not be accessible → Test URL manually

Solution:

Activate check status
Check scheduling settings
Make sure URL is accessible

All Tests Failing

Possible Causes:

URL is wrong or not accessible
Assertion settings are too strict
Timeout duration is too short
Authentication issues

Solution:

Check URL
Review assertion settings
Increase timeout duration
Check authentication information in headers

Notifications Not Coming

Possible Causes:

Notification is in passive status
Notification configuration is incorrect
Email/SMS service is not working

Solution:

Activate notification status
Check notification configuration
Check Email/SMS service settings

Response Times Too High

Possible Causes:

API performance issues
Network delays
Server load

Solution:

Optimize API performance
Check network connection
Check server resources

Results Not Showing

Possible Causes:

Check has not run yet
Date range filter is wrong
Results may have been deleted

Solution:

Make sure check has run
Check date range filter
Make sure results have not been deleted

Additional Resources

Test Console Usage Guide

Creating test scenarios

Connectors

Notification and action configuration

Scheduled Jobs

Scheduling settings and cron expression

API Documentation

REST API usage

Analytics

API Traffic Settings

Reports

Monitoring

​Overview

24/7 Monitoring

Performance Metrics

Early Warning

Automatic Notifications

​What is API Health Check?

​Basic Concept

Critical API Monitoring

SLA Tracking

Performance Monitoring

Uptime Monitoring

​Quick Start

​Creating Your First Health Check

​Creating New Health Check

​Step 1: Basic Information

​Step 2: Scheduling Settings

​Common Scheduling Examples

​Step 3: Request Settings

GET

POST

PUT

DELETE

PATCH

HEAD

​Step 4: Validation Settings

​Step 5: Settings

​Step 6: Retry Settings

​Step 7: Notification Recipients

​Adding Notifications

​Step 8: Saving

​Monitoring and Reporting Results

​Accessing Results Page

​Results Page Sections

​Viewing Result Details

​Deleting All Results

​Health Check Management

​List Page Features

​Best Practices

1. Naming Conventions

2. Scheduling Strategy

3. Assertion Usage

4. Retry Strategy

5. Notification Management

6. Performance Monitoring

​Frequently Asked Questions

​Troubleshooting

​Additional Resources

Test Console Usage Guide

Connectors

Scheduled Jobs

API Documentation

Overview

What is API Health Check?

Basic Concept

Quick Start

Creating Your First Health Check

Creating New Health Check

Step 1: Basic Information

Step 2: Scheduling Settings

Common Scheduling Examples

Step 3: Request Settings

Step 4: Validation Settings

Step 5: Settings

Step 6: Retry Settings

Step 7: Notification Recipients

Adding Notifications

Step 8: Saving

Monitoring and Reporting Results

Accessing Results Page

Results Page Sections

Viewing Result Details

Deleting All Results

Health Check Management

List Page Features

Best Practices

Frequently Asked Questions

Troubleshooting

Additional Resources