Simulate real user flows with advanced synthetic monitoring for your APIs.
Ideal for testing multi-step requests and ensuring end-to-end reliability.

API Resource

Open the dashboard, click the button, and select API Resource from the dropdown menu.

Active/Paused

Choose whether to activate the monitor immediately or keep it paused for now:

• Active: The target is actively polled at the specified frequency to check its status.
• Paused: The target is temporarily inactive and will not be polled until set to active again.

Name and URL

Set the Name and URL for your target. The Name will be used in alerts, reports, and other notifications.

Scan Frequency (API Up/Down Monitoring)

Your API endpoint will be checked at a frequency of every 5 min by default. The minimum allowed frequency is 1 minute and the maximum is 24 hours.

The scan frequency determines how often your API's availability is verified. Setting a shorter interval (e.g., 1 minute) allows you to detect downtime almost instantly. For free users, the minimum frequency is typically 5 minutes, while premium users can set it to 1 minute for near real-time monitoring. Frequent checks are recommended for critical endpoints and help ensure fast alerting in case of failures.

Longer intervals (e.g., 1 hour or more) are suitable for less critical API endpoints where immediate notification is not required. Choose the frequency based on how quickly you need to respond to downtime and the importance of the monitored API.

SSL Certificate Monitoring

Choose whether SSL certificate scanning is Active or Inactive:

• Active: Displays SSL certificate errors, marking the site as down if issues are detected.
• Inactive: Ignores all SSL certificate errors during site/domain pinging.

Choose the SSL check type:

• Basic: Basic SSL check using openssl without detailed certificate checks.
• Advanced: Advanced SSL check with detailed certificate and status verification.

SSL Certificate Expiration Notifications (optional):

• Enable: Displays notifications for SSL certificates nearing expiration, prompting timely renewal.
• Disable: Suppresses all SSL certificate expiry notifications.

Note: This option is optional. For basic Up/Down monitoring over HTTPS, SSL expiry notifications are not required. You can create a separate monitor specifically for SSL certificate expiration alerts if needed.

Domain Expiration Monitoring

Choose whether to enable automatic domain expiration checking:

• Enable: Automatically checks your domain's expiration date and tracks it to ensure you never miss renewal deadlines.
• Disable: Skips checking this domain for expiration. Use this option if the domain does not require active monitoring.

Control domain expiration notifications to receive timely alerts:

• Enable Notifications: Displays alerts for domains nearing expiration, prompting timely renewal to prevent service interruption.
• Disable Notifications: Suppresses all domain expiration notifications. Use this option only if you track renewals manually or through another system.

Domain Expiration Monitoring helps you stay on top of renewal dates and ensures your website, email, and other domain-based services remain uninterrupted. By enabling both domain checks and notifications, you reduce the risk of unexpected downtime and maintain continuous control over your domains.

The request timeout

The request timeout defines how long our monitoring bots will wait for a response from your server before marking the target as down.

Default: 30 seconds
Range: 1 – 60 seconds

Setting a shorter timeout means your target can be marked as down more quickly if responses are slow. This is useful if you want immediate alerts, but using too low values (like 1–5 seconds) may cause false positives, especially during traffic spikes or heavy server load.

Choosing a longer timeout (e.g., 45–60 seconds) makes monitoring more tolerant of slow responses, but it will also delay downtime detection and notifications.

👉 For most cases, we recommend keeping the default 30 seconds for a good balance between speed and reliability.

Successful HTTP Response Codes

You can configure which HTTP status codes should be considered a successful response for your target API. By default, 200 - OK is used, but you may choose other codes depending on your use case.

• 200 – OK
• 201 – Created
• 202 – Accepted
• 204 – No Content
• 206 – Partial Content
• 401 – Unauthorized
• 403 – Forbidden
• 429 – Too Many Requests

👉 For most API monitoring cases, 200 is the standard choice. However, if your endpoint legitimately returns other codes (e.g., 201 after a successful POST, or 204 for empty responses), you can mark them as successful to avoid false "down" alerts.

Content Type & Response Accept

These settings let you control how requests are sent and what type of responses are expected from your API endpoint. By default, application/json is used for both, which is suitable for most API monitoring.

• Content-Type – Defines the format of the data being sent in the request.
  • application/json (default) – Standard JSON payloads
  • application/ld+json – JSON-LD payloads
  • application/merge-patch+json – For partial updates using JSON Merge Patch
• Response Accept – Defines the type of content your monitoring bot expects to receive back.
  • application/json (default) – Standard JSON responses
  • application/ld+json – JSON-LD responses

👉 In most cases, you can keep both settings as application/json. Switch to application/ld+json if your API endpoint returns JSON-LD, or application/merge-patch+json when sending partial updates.

IP Protocols Settings

You can choose which IP protocols to use when monitoring your target. By default, both IPv4 and IPv6 are allowed, and the monitoring bot will decide automatically which protocol to use.

• IPv4 only – All requests will be sent using IPv4. Example: http://1.2.3.4 (an IPv4 address) will only allow IPv4 checks.
• IPv6 only – All requests will be sent using IPv6. Example: http://[2001:db8::1] (an IPv6 address) will only allow IPv6 checks.
• IPv4 + IPv6 (default) – Both protocols are supported, and monitoring will work for any valid hostname or IP address.

👉 If you provide a direct IP address in the URL, the system automatically restricts monitoring to that protocol type (IPv4 or IPv6).

👉 For hostnames (e.g., example.com), you may explicitly choose to monitor only via IPv4 or only via IPv6. This can be useful for:

• Testing whether your service is accessible via both protocols.
• Ensuring IPv6 readiness before migration or deployment.
• Debugging connectivity issues specific to one protocol type.

For most cases, we recommend keeping the default (IPv4 + IPv6) setting, ensuring maximum compatibility and availability.

API Synthetic Mode

API Synthetic monitoring allows you to simulate complex workflows and test multiple API requests in sequence. This mode is ideal for checking critical API operations beyond simple Up/Down monitoring.

• Mode – Select Synthetic Mode to enable sequence-based API testing. This mode must be chosen to use the Synthetic features.
• Sequence – Define the order of HTTP requests to perform. Currently, supported request types in a sequence include POST, GET, and DELETE. This allows you to simulate multi-step API workflows, such as creating, retrieving, and deleting resources.
• Request Body – Paste raw JSON for your API requests here. Each request in the sequence can include its own JSON payload, enabling realistic and customizable API simulations.

👉 Synthetic Mode is especially useful for testing APIs that require multiple steps, validating responses at each stage, and ensuring end-to-end functionality. Always make sure your JSON payloads are correctly formatted to avoid request failures.

Custom Headers

This setting allows you to add custom HTTP headers to each request. Headers are specified as key-value pairs.

Examples of usage:

• Authorization: Bearer <token> – for access control.
• User-Agent: MyScanner/1.0 – to identify your monitoring tool.
• X-Custom-Header: value – for specific backend services or custom logic.

Key points:

• Any number of custom headers can be added.
• If a header conflicts with system headers (e.g., Content-Type or Accept), the user-defined value takes precedence.
• Custom headers allow you to emulate different client behaviors or bypass server restrictions.

✅ Default: none. You only need to add headers if your endpoint requires them.

HTTP Basic Auth Credentials

This setting allows you to provide a username and password for HTTP Basic Authentication. It is used when your target requires authentication to access the content.

Usage notes:

• Enter the Username and Password exactly as required by your server.
• The credentials will be sent securely with each monitoring request using HTTP Basic Auth headers.
• Make sure to use valid credentials to avoid false "down" alerts.

✅ Default: none. Leave empty if your target does not require authentication.

Access Key (API Key / Token)

To authorize API monitoring, you need to provide a valid token. This can be an API Key, API Access Token, or JWT Token depending on your service.

Paste your token in the Authorization Token field. Example: Bearer YOUR_API_TOKEN

👉 This token allows the monitoring bot to authenticate with your API endpoints securely, enabling status checks and custom monitoring. Keep your token safe and do not share it publicly.

How would you like to be notified?

By default, all available notification channels are enabled:

• On the website / In-app
• Email
• Telegram
• Webhook

You can customize which channels to use for this monitor individually, or globally manage permissions for Email, Telegram, and Webhook notifications via your Notification Channels settings.

✅ Recommended: Keep all channels enabled for maximum awareness of uptime issues, but adjust according to your preferences and workflow.