Introduction

Use this endpoint to create a new user account by providing your first name, surname, email address, and password.

Once submitted, the system creates the account and sends a confirmation code to the provided email address. You’ll need to verify this code to activate your account via the Account Confirmation endpoint.

When to use:
This endpoint is used during the signup process on our platform, allowing users to register directly through the app or website.

How it works:
Provide your details – Enter your first name, surname, email, and password.
Send a POST request – The information is sent to our system to create your account.
Check your email – If successful, you’ll get a confirmation message.
Activate your account – Complete signup via the Account Confirmation endpoint.

This endpoint is used to confirm and activate a newly created user account. After a user signs up, a unique confirmation code is automatically sent to their email. This code is required to verify the user's identity and complete the registration process. By submitting the confirmation code along with the email address used during signup, the account will be marked as confirmed and fully activated.

When to use:
Use this endpoint after signing up, when you’ve received a confirmation code and are ready to activate your account.

How it works:
1️⃣ Enter your email and code – Provide the confirmation code and the email address used during signup.
2️⃣ Verify your identity – The system checks the code for accuracy and expiration.
3️⃣ Account activation – If valid, your account is confirmed and ready to use.
4️⃣ Invalid code? – If the code is incorrect or expired, an error is returned and you’ll need to request a new one.

This endpoint is used to resend a confirmation code to a user's email address when the original code has been lost, expired, or not received. It helps users complete the signup process if they were unable to activate their account using the first code. To receive a new code, simply provide the email address used during registration.

Common use case:
If the original confirmation code has expired, was never received, or was accidentally deleted.

How it works:
1️⃣ Enter your email – Provide the same email address used during signup.
2️⃣ Request a new code – The system generates and sends a new confirmation code.
3️⃣ Check your inbox – Use the new code to confirm your account via the Account Confirmation endpoint.

This endpoint is used to log in to your account securely by submitting your registered email address and password. When the provided credentials are correct, the system verifies your identity and grants access to your account.

When to use:
After confirming your account to sign in and start using the platform.

How it works:
1️⃣ Enter your login details – Provide the email and password you used during signup.
2️⃣ Authentication – The system checks your credentials.
3️⃣ Success – If valid, you're logged in and granted access.
4️⃣ Failure – If incorrect, an error message explains what went wrong (e.g., invalid email or password).

This endpoint is used to securely log out of your account by ending your current session. Once logged out, you will no longer have access to protected areas of the platform until you log in again.

Typical scenario:
A user logs out through a sign-out action in the application, ending access to protected resources.

How it works:
1️⃣ Send a logout request – This signals the system to end the active session.
2️⃣ Session ends – The user's access is revoked immediately.
3️⃣ Protected features blocked – Any further actions that require login will be denied until the user signs in again.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• The system will log you out, revoke your session, and invalidate any related tokens.
• If the request is unauthorized or invalid, the system will respond with an error message explaining the issue.

This endpoint is used to complete the password recovery process by verifying the confirmation code and setting a new password. After initiating a password reset, you will receive a confirmation code by email. To reset your password, submit your email, the confirmation code, and your new password.

Use this after you've received a password reset code via email and are ready to set a new password for your account.

How it works:
1️⃣ Provide required details – Submit your email, the code you received, and a new password.
2️⃣ Verification – The system checks the code and validates the input.
3️⃣ Password updated – If successful, your password will be changed and you can log in with the new credentials.

When to use:
Use this when you forget your password and need to reset it to regain access to your account.

How it works:
1️⃣ Enter your email – Submit the email address you used to sign up.
2️⃣ Get a confirmation code – The system will send a password reset code to your inbox.
3️⃣ Proceed to reset – Use the Confirm Password Recovery endpoint to enter the code and set a new password.

Expected Behavior:

• On success, you will receive an email containing a confirmation code to reset your password.
• Use the Confirm Password Recovery endpoint to verify the confirmation code you received via email.
• If the email address is invalid or the request fails, an error message will be returned explaining the issue.

This API endpoint finalizes the password recovery process by allowing you to provide a recovery code and set a new password. After requesting a password reset, you will receive a confirmation code via email. To complete the process, submit your confirmation code, email and newpassword. Upon successful submission, the password will be updated.

Expected Behavior:

• On success, your password will be updated.
• If the recovery code is incorrect or the request is invalid, an error message will be returned.

This endpoint is used to change your current account password. To update your password, you need to provide your current password and a new password that you want to set.

Use this endpoint when you're logged in and want to change your password for security or personal reasons.

How it works:
1️⃣ Submit your current password – This is required to confirm your identity.
2️⃣ Provide a new password – Choose a secure new password to replace the old one.
3️⃣ Receive confirmation – If the current password is correct and the new password is valid, the update will be successful.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the password and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint retrieves the profile information of the currently authenticated customer. It returns a structured response containing essential details about the customer, their team, and associated organization.

You can use this endpoint to display customer profile data in dashboards, account settings pages, or any area where customer-specific context is needed.

Key response fields include:

• Customer: ID, email, full name, role
• Team: ID and name of the associated team
• Organization: name, subscription plan, and trial period
• Limits: available resource and service limits

This allows your application to stay in sync with the customer’s account and access permissions in real time.

Authorization: Bearer YOUR_TOKEN

To make changes or remove the account, See the Update Customer or Delete Customer endpoints.

This endpoint is used to update the profile information of the currently authenticated customer. It supports editing basic customer details such as name and surname to keep account information accurate and up to date.

Apply this endpoint when:
Customers request to update their visible profile information like first or last name.

Supported fields include:

• First name
• Surname

This helps maintain consistent and user-managed customer records across your application.

Authorization: Bearer YOUR_TOKEN

Looking for full profile access or removal? Refer to Get Customer or Delete Customer.

This endpoint is used to permanently delete a customer account from the system. To perform this action, a valid deletion reason must be provided.

When to use:
When a customer requests account removal or when the account must be deactivated for business, compliance, or security reasons.

Important notes:

• This action is irreversible — all associated data will be removed.
• A reason for deletion is required for auditing and record-keeping purposes.

This endpoint helps enforce data control and compliance with user account management policies.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will delete the customer record and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

Need to view or update customer details instead? Visit Get Customer or Update Customer.

This endpoint is used to update the username of the currently authenticated customer. To perform the update, a valid email address must be provided as part of the request to ensure ownership and verification.

Use this endpoint when a customer needs to change their existing username — for example, after an email change, rebranding, or correcting a previous entry.

This ensures that each customer's username remains unique and tied to their verified email identity.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the username will be updated, and a message will confirm that verification is required. To complete the process, you need to verify the new username using the Confirm Customer Username Change endpoint.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint is used to confirm a username change for the currently authenticated customer. After initiating a change, a confirmation code is sent to the associated email address. To finalize the update, submit this code.

You can call this endpoint after calling Update Customer Username to verify and apply the new username.

This verification step ensures that all username changes are authorized and securely confirmed by the account owner.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will verify the username and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This API endpoint allows creating a new personal notification channel. Notification channels can include SMS, email, or other communication methods used to deliver updates, alerts, or promotional information to the customer. You must include the value and type of the notification channel.

Common use cases:

• SMS notifications: Use this endpoint to configure an sms notification channel for sending alerts or updates directly to the customer’s phone.
• Email notifications: Set up an email notification channel to keep customers informed about important alerts, updates, ensuring they receive timely information.
• Push notifications: Add a webhook or other URL-based notification method to send push notifications or real-time updates to external platforms integrated with customer data.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will create the notification channel and return a confirmation message. To complete the verification process, please use the Verify Personal Notification Channel endpoint.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint retrieves all notification channels that are currently configured for the authenticated customer. These channels define how the customer receives alerts and system notifications (e.g., via email or webhooks).

Designed for:
Listing all communication channels a customer has set up, allowing administrators or users to confirm notification preferences.

Response may include:

• Channel type (e.g., email, webhook)
• Status (enabled/disabled)
• Verification state
• Delivery endpoint or address

To update or test a channel, see the Update Notification Channel or Test Notification Channel endpoints.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will return the customer's notification channels, including their details such as type, priority, and status. The priority parameter indicates the importance level of the notification channel.
• If the request is unauthorized, the system will respond with an authentication error message.

This endpoint allows you to update an existing notification channel for the authenticated customer. It is used to modify properties such as the channel value (e.g., email address or webhook URL) and priority level.

Use this where:
A customer wants to change where or how they receive system notifications — for example, updating their email or changing the importance of a channel.

Important notes:

• The request must include the channel type and updated values
• The channel must already exist — this endpoint cannot create new channels
• Changes may affect how and when the customer receives alerts

To view existing channels, use the Get Notification Channels endpoint. To test delivery after updating, use the Test Notification Channel endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the specified notification channel and return a confirmation message indicating that the updated channel needs to be verified. To complete the verification process, please use the Verify Personal Notification Channel endpoint.
• If the request is unauthorized or invalid, the system will respond with an appropriate error message.

This endpoint is used to verify a notification channel for the authenticated customer. It is typically called after a new notification channel (e.g., an email address) has been added or updated, and requires confirmation.

This step helps verify that the notification channel is legitimate and trusted before allowing message delivery.

Important notes:

• The request must include the confirmation code sent to the channel (e.g., via email)
• Priority may also be included to identify or reorder channels if required
• Only unverified channels can be confirmed using this endpoint

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will verify the notification channel and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to delete a specific notification channel configured for the authenticated customer. The notification channel to be removed is identified using the priority value passed as a query parameter.

When to use:
A customer wants to stop receiving alerts via a specific channel or wishes to remove outdated contact methods.

Important notes:

• The priority parameter is required to identify which channel to delete
• Only channels associated with the authenticated customer can be removed
• Once deleted, the channel must be re-added if needed in the future

To view or modify channels before deletion, use the Get Notification Channels or Update Notification Channel endpoints.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified notification channels will be deleted, and the system will return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an appropriate error message, indicating the issue.

This endpoint allows you to send a test message to one of the customer's configured notification channels. It helps confirm that the channel is set up correctly and able to receive notifications.

Typical scenario:
Run this after adding or enabling a notification channel to make sure messages are delivered successfully.

Important notes:

• The priority of the channel to test must be included in the request
• Sends a non-intrusive test message — does not trigger real alerts
• Useful for validating setup and troubleshooting delivery issues

To configure channels before testing, see the Create Notification Channel or Enable Notification Channel endpoints.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will send a test message to the notification channel and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to enable or disable a specific notification channel for the authenticated customer. It is used to control whether alerts are actively delivered to a given channel without deleting it.

Recommended when:
A notification channel needs to be deactivated temporarily or reactivated later for continued use.

Important notes:

• The request must include the enabled field (boolean) and the priority of the channel
• Setting enabled: false deactivates delivery, while true reactivates it
• This action does not delete or modify the channel configuration

To test the channel after enabling it, use the Test Notification Channel endpoint. To permanently remove a channel, see Delete Notification Channel.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the enabled status of the notification channel and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an appropriate error message, such as unauthorized access or invalid input.

This endpoint allows you to create a new team within your organization to support structured monitoring and collaboration. Teams help you group users based on their responsibilities and distribute key operational tasks across different roles.

Helpful when:
You need to assign specific monitoring responsibilities to distinct teams within your organization.

Benefits:

• Assign ownership of systems or services to specific teams
• Improve incident response by defining roles and access levels
• Streamline alert handling and reduce operational noise

Once a team is created, you can add members and configure team-specific notification channels for effective communication.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will create the team and return a confirmation message along with the team details.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to retrieve a list of all teams within your account or organization. It returns an array of team records, each containing key metadata to help you identify and manage your teams effectively.

When to use:
Display team data in dashboards, manage memberships, or perform audits across your organization.

Returned data includes:

• team_id – Unique identifier for the team
• name – Name of the team
• member_count – Total number of users in the team
• created_at – Timestamp of when the team was created

For managing individual teams, see the Update Team or Delete Team endpoints.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will return a list of teams along with their details.
• If the request is unauthorized, the system will respond with an authentication error message.

This endpoint allows you to update the details of an existing team by modifying its name. It is useful for keeping team information organized and aligned with current team roles or purposes. When a team’s name needs to be changed due to organizational updates, restructuring, or naming standardization, you can use this endpoint.

Important notes:

• You must provide the updated name for the team
• The team_id is used to identify which team to update

To view a list of teams before updating, use the Get Teams endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the team information and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to remove an existing team from your account. Once deleted, the team and its associated relationships will no longer be available in the system.

Use this to:
Delete a team following restructuring, team consolidation, or when clearing unused resources.

What happens on deletion:

• The team is permanently removed from your organization
• Team memberships and related settings will no longer be accessible
• This action does not affect any customer or service data assigned outside of the team

Before deleting, you can review existing teams using the Get Teams endpoint or update team details with the Update Team endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will delete the team and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to retrieve details of invitations that have been sent out to join teams within your organization. It provides full visibility into the invitation lifecycle to help you manage team onboarding efficiently.

Recommended when:
You need visibility into invitation history and current status while assembling your team.

Returned data includes:

• channel – The name of the invitation channel
• channel_type – Delivery method used (e.g., email)
• sender_full_name – Name of the person who sent the invitation
• created_at – When the invitation was created
• reminded_at – Timestamp of the last reminder sent
• status – Invitation status (Pending, Accepted, or Declined)

For sending new invitations, refer to the Invite Team Member endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will return a list of team invitations and their statuses.
• If the request is unauthorized, the system will respond with an authentication error message.

This endpoint allows you to invite a new member to your team by specifying their contact details and preferred delivery method. It supports sending invitations through various communication channels, such as email. When you want to add collaborators to a team and initiate the onboarding process, you can call this endpoint.

Required fields:

• channel_value – The destination address (e.g., email address)
• channel_type – The method used to send the invitation (e.g., email)

After sending the invite, you can monitor its status using the Get Team Invitation Details endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will generate an invitation for the new team member and return a confirmation message.
• If the request is unauthorized or contains invalid parameters, the system will respond with an appropriate error message.

This endpoint allows you to delete a previously sent team invitation that has not yet been accepted. It is useful for canceling outdated, incorrect, or unwanted invitations during team setup or membership adjustments.

Recommended when:
A team invitation remains unanswered or needs to be canceled before being acted upon.

Required field:

• channel_value – The address (e.g., email) to which the invitation was sent

To track invitation status before deletion, use the Get Team Invitation Details endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will delete the specified team member invitation and return a confirmation message.
• If the request is unauthorized or contains invalid parameters, the system will respond with an appropriate error message.

This endpoint allows you to retrieve a list of all team members associated with a specific team. It returns structured data that includes key details for each member, helping you manage roles, permissions, and team composition.

You can use this endpoint to display current team membership in dashboards, verify access levels, or audit team participation.

Returned data includes:

• customer_id – Unique identifier of the team member
• email – Member’s contact email
• name – Full name of the team member
• role – Role assigned within the team (e.g., root, manager)

To remove a member, use the Delete Team Member endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will return a detailed list of team members along with their associated information.
• If the request is unauthorized, the system will respond with an authentication error message.

This endpoint allows you to remove a specific member from a team. It is used to revoke access for users who no longer require team participation, ensuring that only active, authorized individuals remain part of your team structure.

When to use:
A team member has left the organization, changed roles, or no longer needs access to team resources or monitoring tools.

To view all current team members before removal, use the Get Team Members endpoint. To invite new members in their place, see the Invite Team Member endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will delete the specified team member and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an appropriate error message.

This endpoint allows you to update a team member’s role or move them to a different team. It helps maintain proper access control and team alignment across your organization.

Common use case:
Updating a team member’s role or moving them to a different team using the new_team_id field.

Important notes:

• If the member should remain in the current team, you can leave new_team_id unchanged
• Role changes take effect immediately upon update

To review the current team structure before updating, use the Get Team Members endpoint. To remove a user instead, refer to the Delete Team Member endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the team member and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to send a reminder for a pending team invitation that has not yet been accepted. It is useful for nudging invited users who may have missed or forgotten the original invite. You can use this endpoint to follow up with users who have not yet responded to their invitation to join a team.

Required field:

• channel_value – The destination address where the original invitation was sent (e.g., email)

To check invitation status before sending a reminder, use the Get Team Invitation Details endpoint. To cancel the invitation entirely, refer to the Delete Team Member Invitation endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will send the invitation reminder and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

Notification channels are used to send alerts or messages to teams through various mediums, such as webhooks, email, or other integrations. To create new team notification channel you must provide the value and type.

Common use cases:

• Create webhook for alerts: Add a webhook URL to enable real-time notifications for system alerts, incidents, or other events to be sent to the team’s communication platform.
• Set up email alerts: Configure an email address to receive important alerts or updates related to the team's operations, ensuring critical notifications are not missed.
• Integrate with external systems: Add an external service or tool (e.g., Slack, PagerDuty) as a notification channel to centralize team communication for incidents and system updates.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will create the notification channel and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to retrieve all notification channels that are currently configured for a specific team. These channels determine how the team receives system alerts, incident reports, and other operational messages.

Apply this when:
Managing team preferences or auditing communication flows tied to monitoring events.

Returned data typically includes:

• Channel type (e.g., email, webhook)
• Channel value (e.g., email address or URL)
• Status (enabled or disabled)
• Verification state

To modify or test one of these channels, use the Update Team Notification Channel or Test Team Notification Channel endpoints.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will return the team’s notification channels, including their details such as type, priority, and status. The priority parameter indicates the importance level of the notification channel.
• If the request is unauthorized, the system will respond with an authentication error message.

This endpoint allows you to update a notification channel associated with a specific team. You can change how and where the team receives critical alerts by modifying the channel’s configuration.

Common workflow:
Modify a team’s existing notification channel as part of regular communication maintenance.

Required fields:

• value – The new destination for notifications (e.g., email address or URL)
• priority – Identifies the specific channel to be updated

To review existing channels before updating, use the Get Team Notification Channels endpoint. After making changes, you can test delivery using the Test Team Notification Channel endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will add the new notification channel and return a confirmation message indicating that the channel needs to be verified. To complete the verification process, please use the Verify Team Notification Channel endpoint.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint allows you to verify a team notification channel after it has been added or updated. Verification ensures the channel is functional and authorized to receive notifications on behalf of the team.

Required step:
Authenticate ownership of the new channel by providing the code sent to its destination (email or webhook).

Required fields:

• code – The verification code sent to the notification destination
• priority – Identifies the channel being verified

To set up or change a channel before verification, see Create or Modify team notification channel endpoints.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will verify the notification channel and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

Remove an unwanted notification channel from a team to ensure alerts are only sent to valid, actively monitored destinations. This is particularly useful when retiring outdated email addresses, rotating webhook URLs, or simplifying the team’s communication structure. The channel to be deleted is identified using its priority value passed as a query parameter.

Deleting a channel stops all system messages from being routed through it. To prevent delivery issues or confusion during incidents, make sure a replacement channel is already configured if necessary.

You can view existing team channels before deletion using the Get Team Notification Channels endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will delete the specified notification channels and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

This endpoint sends a simulated message to a specified team notification channel to confirm that it is operational. It is commonly used right after creating, updating, or enabling a channel to ensure it can successfully receive system-generated alerts.

The test does not send real alerts but mimics an actual delivery to validate connectivity, format compatibility, and proper configuration. This helps teams identify setup issues before relying on the channel in live monitoring environments.

Use this feature as a routine step when onboarding new teams, rotating email/webhook endpoints, or verifying channel health after extended inactivity.

Need to view or configure channels before testing? Head over to Get Team Notification Channels or Update Team Notification Channel.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will send a test message to the specified notification channel and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

Control the activation state of a team's notification channel by toggling it on or off. This endpoint lets you enable or disable a specific channel without deleting it — giving teams the flexibility to pause alert delivery during maintenance windows or while rotating contact methods.

To perform the update, you must specify the priority of the channel and set the enabled flag to either true (to activate) or false (to deactivate).

Disabling a channel prevents it from receiving any system alerts until it's re-enabled. This is useful when troubleshooting delivery issues, reducing noise during off-hours, or enforcing temporary alert silencing for specific teams.

For visibility into all available team channels, use Get Team Notification Channels. To test a channel after enabling it, see Test Team Notification Channel.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the notification channel status and return a confirmation message.
• If the request is unauthorized or invalid, the system will respond with an error message.

Create a new service within the context of a specific team in your monitoring system. In this structure, each service is owned and managed by a team, allowing for better organization, role-based visibility, and scoped alert handling.

To create a service, include the name of the service and the team_id it belongs to in the request body. This association ensures that each team is responsible for monitoring and responding to events tied to its own services.

Real-world use cases:

• Team-specific service tracking — Allow different teams to independently monitor their own microservices, apps, or integrations.
• Structured growth — As your system scales, teams can register new services under their scope to maintain separation of responsibilities.
• Improved alert ownership — Alerts and incidents triggered from the service can be routed to the right team based on the team_id assignment.

After a service is created, it can be connected to uptime monitors, incident workflows, and team-based notification channels for complete operational visibility.

Authorization: Bearer YOUR_TOKEN

Rename an existing service in your monitoring system to better reflect its current role, ownership, or purpose. This endpoint helps keep service names consistent with organizational changes — such as product renaming, infrastructure restructuring, or shifts in team responsibilities.

To perform the update, provide the service's unique identifier (service_id) as a path parameter and the new name in the request body. This change is reflected across all related views, including dashboards, incident logs, and monitor assignments.

Why this is useful:

• Clarity in operations — Rename services to match new internal naming conventions or business terminology.
• Reduce confusion — Keep service names descriptive and current so that team members and stakeholders clearly understand their purpose.
• Avoid data fragmentation — Update rather than recreate services to preserve historical monitoring and incident data tied to the original service.

To view the current details of a specific service before renaming, use the Get Service Details endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the service name will be updated, and a confirmation message will be returned.
• If the request is unauthorized, an error message indicating authorization failure will be returned. If the request is invalid or contains incorrect data, a message specifying the issues will be provided.

Remove a service from your monitoring system when it is no longer relevant, active, or needed. This endpoint permanently deletes the service and dissociates it from any connected monitors, alerts, or incidents.

To perform the deletion, provide the service_id as a path parameter. The service will be removed from the associated team’s structure, ensuring the system remains clean, organized, and free from unused entries.

When deletion is useful:

• Retiring legacy systems — Remove services that are no longer deployed or supported.
• Avoiding alert noise — Eliminate inactive services to prevent confusion or irrelevant alerts.
• Keeping dashboards relevant — Ensure only current and meaningful services are shown to teams and stakeholders.

If you need to rename a service instead of deleting it, use the Update Service Name endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the service will be deleted, and a confirmation message will be returned.
• If the request is unauthorized, an error message will indicate authorization failure. If the service ID is invalid or not found, a message specifying the issue will be provided.

Retrieve full details about a specific service using its service_id. This endpoint provides key information such as the service name, its unique identifier, and usage statistics — helping teams monitor and manage their assigned services more effectively.

Returned data includes:

• name – The name of the service
• service_id – The unique identifier assigned to the service
• resource_count – Number of resources (e.g., servers, APIs) connected to the service
• heartbeat_count – Number of heartbeat monitors associated with the service

This information is useful when performing audits, viewing service usage, or verifying ownership before updating or deleting the service.

Authorization: Bearer YOUR_TOKEN

Create a new uptime monitor to track the availability and responsiveness of a service or endpoint. Uptime monitors run periodic checks using protocols such as HTTP, TCP, ICMP (ping), SMTP, UDP, POP, or IMAP — giving you flexibility to monitor everything from APIs to mail servers and network ports.

To configure a monitor, provide a name, select a type from the supported protocols, specify the associated service_id, and define conditions (such as response time thresholds, port availability, or expected response codes). You can also customize options like whether to follow redirects or ignore SSL certificate errors for applicable types.

Use cases include:

• Web service monitoring (HTTP) — Ensure uptime for websites and APIs with customizable response validation.
• Ping/ICMP checks — Monitor server availability using lightweight network pings.
• Mail server health (SMTP, IMAP, POP) — Validate that your inbound and outbound email systems are reachable and responding.
• Port and protocol monitoring (TCP/UDP) — Check the availability of services running on specific ports or protocols.

After creation, the monitor will run continuously and log performance metrics and availability history. This data powers uptime charts, incident alerts, and trend analysis.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, a new uptime resource will be created, and a confirmation message will be returned.
• If the request is unauthorized or invalid, an error message will be returned.

Efficiently remove multiple uptime monitors in one operation by passing their ids as a query parameter array. This bulk deletion feature is ideal for large-scale cleanup tasks, such as retiring services, restructuring environments, or clearing out test monitors after staging deployments.

Instead of making individual delete requests for each monitor, this endpoint allows you to streamline operations by submitting a list of monitor IDs in a single call — saving time and reducing API overhead.

Common use cases include:

• Service decommissioning — Remove all monitors associated with a shutdown system or deprecated feature set.
• Bulk cleanup — Delete outdated, duplicated, or test monitors during infrastructure reorganization.
• Workspace resets — Prepare clean environments by clearing monitors in bulk between testing or onboarding phases.

To fetch monitor IDs before deletion, use the Get Uptime Monitors endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified uptime monitoring resources will be deleted, and a confirmation message will be returned.
• If the request is unauthorized or the IDs are invalid, an appropriate error message will be returned.

Toggle the operational status of an existing uptime monitor by enabling or disabling it as needed. This endpoint gives teams fine-grained control over monitoring activity — allowing them to pause or resume checks without permanently deleting the monitor.

To update the status, include the monitor_id in the path and provide the enabled flag in the request body, set to true to activate the monitor or false to deactivate it.

When to use this:

• Scheduled maintenance — Temporarily disable monitoring to avoid false-positive alerts during planned downtimes.
• Service deactivation — Pause monitoring for services that are temporarily offline or in standby mode.
• Reactivation — Re-enable monitors once the related service is stable and ready to be tracked again.

This functionality is useful for reducing alert noise, maintaining clean uptime logs, and ensuring accurate incident tracking without losing historical data tied to the monitor.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the status of the uptime resource will be updated, and a confirmation message will be returned.
• If the request is unauthorized or the provided ID is invalid, an error message will be returned, specifying the issue.

Permanently remove a specific uptime monitor by providing its monitor_id in the request path. Once deleted, the monitor will no longer perform health checks, collect availability data, or trigger alerts for the associated service.

This endpoint is useful when a monitored service has been retired, replaced, or is no longer relevant to your team’s operational needs. It ensures your monitoring environment remains clean and focused only on active, meaningful targets.

Key scenarios:

• Service decommissioning — Remove monitors tied to systems that are permanently shut down.
• Monitor cleanup — Eliminate unused or outdated monitors to simplify your workspace and reduce visual clutter.
• Avoid unnecessary alerts — Prevent alerts from triggering on endpoints that are intentionally offline or out of scope.

Note: This action is irreversible. To temporarily pause a monitor instead, consider using the Change Uptime Monitor Status endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified uptime resource will be deleted, and a confirmation message will be returned.
• If the request is unauthorized or the provided ID is invalid, an error message will be returned specifying the issue.

Modify the configuration of an existing uptime monitor by providing its monitor_id in the URL path and the updated settings in the request body. This endpoint allows you to adjust the monitor’s name, type, conditions, or other parameters without needing to delete and recreate it.

It is especially useful for keeping monitoring rules aligned with evolving infrastructure — such as changing alert thresholds, updating monitored URLs or ports, or adapting to service changes.

Use cases include:

• Adjusting response conditions — Change HTTP status code expectations, response time thresholds, or content checks.
• Reassigning monitors — Move a monitor to another service by updating its associated service_id.
• Refining alert scope — Update SSL settings, redirect handling, or probe intervals to reduce false positives or improve precision.

To retrieve current values before updating, use the Get Uptime Monitor Details endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified uptime resource will be updated, and a JSON object containing the updated resource details will be returned.
• If the request is unauthorized, or details are invalid, an error message will be returned specifying the issue.

Create a custom reminder for a Top-Level Domain (TLD) by providing the resource_id in the path and specifying reminder settings in the request body. This endpoint helps ensure critical events like domain expirations or renewals are not missed by triggering notifications in advance based on your configured timeline.

Reminders can be tailored to fire a set number of days before the domain’s expiration or renewal date, ensuring your team or clients have time to take action. These alerts help maintain service continuity, prevent downtime, and support proactive domain management.

Common use cases:

• Domain expiration tracking — Notify users a few days before a domain is set to expire, allowing time to renew and avoid accidental lapses.
• Renewal deadline alerts — Send early reminders to stakeholders when domain renewal windows approach, especially for mission-critical domains.
• Custom domain-related events — Set reminders tied to DNS updates, registrar changes, or legal/compliance events associated with the domain.

You can view and manage current domain configurations via the TLD Settings page.

Authorization: Bearer YOUR_TOKEN

Update the configuration of an existing TLD (Top-Level Domain) reminder by specifying the resource_id in the path and submitting the updated reminder details in the request body. This allows you to fine-tune when reminder notifications are sent to better align with current domain management timelines.

You can update the number of days before the event when the reminder should be triggered (e.g., change a 7-day reminder to 3 days) — all without needing to recreate it.

Use cases include:

• Adjusting timing — Modify the reminder trigger window to match updated domain renewal or review policies.
• Ongoing maintenance — Keep reminder settings aligned with internal workflows as service or ownership structures change.

To review current domain configurations and linked reminders, visit the TLD Settings page.

Authorization: Bearer YOUR_TOKEN

Permanently remove a previously configured reminder for a TLD (Top-Level Domain) by specifying its resource_id in the path. Once deleted, the system will no longer trigger notifications for the associated domain expiration or event.

This endpoint is useful for keeping your domain monitoring environment clean and relevant by discarding reminders that are outdated, no longer needed, or were set in error.

Common scenarios:

• Domain decommissioning — Remove reminders tied to domains that are being retired or transferred.
• Reminder cleanup — Delete unnecessary or duplicated reminders to reduce clutter in TLD settings.
• Resetting configurations — Clear a reminder before re-adding it with updated settings.

To view all configured domain reminders, go to the TLD Settings page.

Expected Behavior:

• On success, the TLD reminder will be deleted, and a confirmation message will be returned.
• If the request is unauthorized or the provided ID is invalid, an error message will be returned, specifying the issue.

Authorization: Bearer YOUR_TOKEN

Create an automated reminder for an SSL certificate by providing the associated resource_id in the path and specifying reminder settings in the request body. This ensures your team is notified before the certificate expires, helping prevent service disruptions and trust issues caused by lapsed security credentials.

You can configure the number of days in advance the reminder should trigger (e.g., 7 or 14 days before the expiration date), giving your team enough time to take renewal actions.

Common use cases:

• SSL certificate expiration tracking — Set up proactive reminders to avoid missing critical renewal deadlines for HTTPS-enabled services.
• Security compliance — Ensure SSL certificates are renewed in a timely manner to maintain compliance with security standards.
• Operational continuity — Prevent last-minute renewals or outages due to expired SSL certs across monitored services.

You can view and manage existing reminders via the SSL Settings page.

Authorization: Bearer YOUR_TOKEN

Update the settings of an existing SSL certificate expiration reminder by specifying the associated resource_id in the path and submitting new reminder details in the request body. This allows you to adjust how far in advance your team is alerted about upcoming certificate expirations.

You can change the number of days before the expiration date when the reminder should trigger (e.g., updating a 14-day reminder to 7 days) without needing to recreate the reminder.

Use cases:

• Adjusting lead time — Modify when reminders are sent to better align with internal workflows or vendor renewal cycles.
• Optimizing alert timing — Shorten or extend the reminder window based on how quickly your team can renew certificates.
• Ongoing SSL tracking — Maintain accurate and up-to-date reminder schedules across all SSL-monitored services.

To review existing configurations, visit the SSL Settings page.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the SSL reminder will be updated, and a confirmation message will be returned.
• If the request is unauthorized or the provided service ID is invalid, an error message will be returned, specifying the issue.

Permanently remove an SSL certificate expiration reminder by specifying the related service_id in the path. Once deleted, no future alerts will be sent for the SSL certificate tied to that service, giving you full control over which reminders remain active.

This is useful when a certificate is no longer in use, has been renewed with automated management, or when you're reorganizing SSL tracking across multiple services.

Common scenarios:

• Certificate deprecation — Remove reminders tied to legacy services or certificates no longer being monitored.
• Switching to automated renewals — Eliminate manual reminders for certs that are now managed by tools like Let’s Encrypt or cloud providers.
• Reducing noise — Clean up irrelevant or duplicate reminders to keep your SSL alerting streamlined.

To modify a reminder instead of deleting it, use the Update SSL Reminder endpoint.
To review current SSL reminder configurations, visit the SSL Settings page.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the SSL reminder will be deleted, and a confirmation message will be returned.
• If the request is unauthorized or the provided service ID is invalid, an error message will be returned, specifying the issue.

Fetch a complete list of uptime monitors associated with a specific service by providing its service_id in the URL path. This endpoint returns all monitors configured to track the service's availability, offering a centralized view of its monitoring coverage.

To support large datasets, the endpoint includes built-in pagination via the limit and page query parameters. This makes it easy to retrieve monitors in manageable chunks, especially in environments where dozens or hundreds of monitors may exist across different protocols and endpoints.

Why it's useful:

• Operational visibility — Understand how a service is being monitored across HTTP, TCP, ICMP, and other supported protocols.
• Maintenance readiness — Identify active monitors before performing updates or pausing monitoring during deployments.
• Audit and scaling — Review monitor distribution to ensure coverage is complete and eliminate redundant or outdated monitors.

To add a new monitor to a service, use the Create Uptime Monitor endpoint.

Authorization: Bearer YOUR_TOKEN

Retrieve the full configuration and status details of a specific uptime monitor by providing its monitor_id in the URL path. This endpoint returns essential information about the monitor, such as its type (e.g., HTTP, TCP, ICMP), target URL or IP, check frequency, response validation rules, and current operational state.

It’s particularly useful for teams that need to inspect individual monitor settings, verify deployment status, or troubleshoot monitoring behaviors tied to a single service component.

Use cases:

• Configuration review — Check how a monitor is currently set up before making updates or changes.
• Status validation — Confirm that a monitor is active and tracking the correct endpoint.
• Incident follow-up — Investigate the setup of a monitor involved in recent downtime or alert events.

To browse all monitors associated with a service, use the Uptime Monitoring Records Collection endpoint.

Authorization: Bearer YOUR_TOKEN

Retrieve the list of monitoring regions assigned to a specific uptime monitor by providing its monitor_id in the URL path. Each region represents a geographic location from which health checks are performed, allowing teams to track service availability across different parts of the world.

This is especially valuable for identifying location-specific issues, validating global uptime, or optimizing regional infrastructure coverage.

Use cases:

• Regional diagnostics — Investigate performance differences or outages limited to certain geographic zones.
• Coverage verification — Ensure that a monitor is checking from all required regions based on your application's user base.
• Infrastructure planning — Align uptime checks with regional deployments to detect latency or access issues more accurately.

To update region settings, use the appropriate monitor configuration or update endpoint tied to your uptime monitoring service.

Authorization: Bearer YOUR_TOKEN

Retrieve SSL certificate details for a specific uptime monitor by providing its monitor_id in the URL path. This endpoint returns information such as certificate validity dates, issuer, and expiration status — helping ensure that HTTPS-enabled services are not only available but also securely configured.

It is particularly useful for proactively managing certificate health and avoiding downtime or trust issues caused by expired or misconfigured SSL certificates.

Use cases:

• SSL expiration tracking — Monitor the expiration timeline of certificates associated with your uptime monitors.
• Security auditing — Verify that a valid and trusted certificate is in place across monitored services.
• Incident prevention — Detect expiring or mismatched certificates before they trigger user warnings or service disruptions.

To receive expiration alerts in advance, consider configuring reminders through the Set SSL Expiration Reminder endpoint.

Authorization: Bearer YOUR_TOKEN

Retrieve the Top-Level Domain (TLD) details associated with a specific uptime monitor by providing its monitor_id in the URL path. This endpoint returns information such as the domain name, registrar details, and expiration dates — offering visibility into the domain’s lifecycle and administrative metadata.

It helps teams ensure that the domains being monitored remain valid, properly registered, and renewed on time to avoid service interruptions tied to expired or mismanaged domains.

Use cases:

• Domain expiration tracking — Check how much time remains before a domain expires so renewals can be handled proactively.
• Administrative validation — View registrar data or TLD origin details for compliance, ownership, or audit purposes.
• Infrastructure reliability — Ensure that domain-related issues do not impact uptime monitoring or user access.

To receive alerts for upcoming TLD expirations, use the Set TLD Expiration Reminder endpoint.

Authorization: Bearer YOUR_TOKEN

Retrieve the SSL certificate reminder configuration for a specific resource by providing its service_id in the URL path. This endpoint returns the settings associated with SSL expiration alerts — including how many days before expiration the reminder is set to trigger.

It helps teams verify that reminders are properly configured to avoid missing certificate renewals, ensuring continuous HTTPS availability and trust for end users.

Use cases:

• Reminder audit — Check if SSL alerts are enabled and set to trigger within the appropriate timeframe (e.g., 7 or 14 days in advance).
• Team coordination — Review reminder settings before transferring certificate management responsibilities.
• Expiration risk reduction — Ensure every active SSL-enabled service has a reminder set to prevent lapses.

To update the timing or configuration of an existing reminder, use the Update SSL Reminder endpoint.

Authorization: Bearer YOUR_TOKEN

Retrieve the Top-Level Domain (TLD) reminder configuration for a specific resource by providing its resource_id in the path. This endpoint returns the reminder settings that are used to notify teams about upcoming domain expirations or other critical TLD-related events.

It helps ensure that domains tied to active monitoring services are not overlooked and that reminders are properly configured to allow time for renewal or compliance actions.

Use cases:

• Reminder verification — Confirm whether a TLD reminder is set for a given domain and how far in advance it triggers.
• Renewal planning — Audit reminder settings as part of domain renewal cycles or registrar management workflows.
• Operational visibility — Ensure that all mission-critical domains have proactive alerts in place to avoid expiration-related downtime.

To adjust reminder timing or update existing settings, use the Update TLD Reminder endpoint.

Authorization: Bearer YOUR_TOKEN

Access a performance and uptime summary for a specific monitor by providing its monitor_id in the path. The report includes time-series data reflecting each health check, along with aggregated uptime and response statistics.

Query parameters such as start_date, end_date, interval, and limit allow you to customize the data range and granularity to suit your analysis needs. Whether you're reviewing a short outage window or generating monthly performance reports, this endpoint provides the visibility you need.

The response highlights historical availability, tracks state changes, and measures service responsiveness, helping teams spot trends, validate SLAs, and investigate anomalies in uptime behavior.

Authorization: Bearer YOUR_TOKEN

This API allows you to monitor the state changes of your website or API in real-time. After adding a monitor, you can use this API to monitor state changes and view historical logs.

What is the API Used for?
This API provides you with historical state changes of the monitor and is useful in the following situations:
✅ Monitoring Downtime Events - See when the monitor goes down and when it recovers.
✅ Analyze Errors - Find out the cause of the problem, HTTP status code and other details.
✅ Perform a regional investigation - Determine in which region the error occurred.
✅ Confirm recovery - Verify that the monitor returns 200 OK responses after correcting the error.

How does it work?
1️. Create monitor - Add a monitor for your website or API via the Create Uptime Monitor API.
2️. Detect the problem - When a server error or connection problem occurs, the API logs an event.
3️. View event logs - Get the cause of the error, the time it occurred, and the status code.
4️. Resolve the issue - After restoring the service, confirm the new state and get a 200 OK response.

Authorization: Bearer YOUR_TOKEN

This endpoint allows you to fetch a chronological list of individual HTTP responses logged during uptime monitoring for a specific resource, identified by its unique id. The log entries include precise response metadata—such as timestamp (checked_at), response time in milliseconds, HTTP status code, response headers, and whether the response was considered up and approved from the monitoring location.

This log history provides critical visibility into how a resource behaved over time from specific regions. It’s designed to help SREs, DevOps engineers, and monitoring analysts diagnose transient issues, verify downtime claims, review HTTP performance at specific points, and ensure SLA compliance.

You can optionally narrow the scope of the response by using query parameters such as start_date and end_date to define a time range, and limit to restrict the number of results. Each response object includes granular network-level data that is crucial for analyzing uptime reliability and service responsiveness at a per-request level.

Recommended Use Cases:

• Reviewing detailed uptime behavior during incident post-mortems.
• Auditing resource availability over a specific reporting period.
• Cross-verifying with synthetic test results or external monitoring data.

Authorization: Bearer YOUR_TOKEN

Retrieve all integration channels connected to a specific uptime monitor by providing its monitor_id in the path. This endpoint returns the alerting and automation tools that are actively linked to the monitor — such as email, Slack, webhook URLs, or other third-party services.

It provides clear visibility into how incidents from this monitor are being routed and which communication or response systems are set up to handle alerts.

Use cases:

• Integration audits — Verify that the correct channels are connected and active for timely incident alerts.
• Troubleshooting — Identify why notifications may not be triggering by confirming which integrations are in use.
• Compliance and reporting — Review alert delivery setups for documentation or operational consistency.

To modify these connections, use the corresponding integration management endpoints within your monitoring settings.

Authorization: Bearer YOUR_TOKEN

This API endpoint allows you to create a resource integration by providing the service ID as a path parameter and defining the integration details in the request body. Resource integrations are used to establish a connection between internal services and external platforms, enabling seamless communication and synchronization.

Common use cases:

• Incident reporting integration: Automatically report service issues or incidents to external platforms, like StatusPage, to keep stakeholders informed.
• Monitoring integration: Connect internal resources to monitoring tools, ensuring real-time alerts and data synchronization when key conditions are met.
• Status synchronization: Maintain real-time status updates between your service and external systems, ensuring that all platforms reflect the current state of the service.

Authorization: Bearer YOUR_TOKEN

Update the payload details for an integration linked to an uptime monitor by providing the service_id and integration_id in the path. The request body should include fields such as name, status, message, and a list of affected items (e.g., resource IDs or related entities).

This endpoint is used to update the incident details stored in the integration channel. It ensures that when alerts are triggered, they contain the most accurate and relevant information about the incident.

Use cases:

• Message personalization — Modify alert content to match internal naming conventions or team communication style.
• Status coordination — Reflect real-time incident status changes in downstream tools via updated integration payloads.
• Targeted alerting — Attach specific items or affected resources to help teams respond faster and more accurately.

To review existing integration settings for a monitor, use the Uptime Monitor Integrations Retrieval endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the integration will be updated, and a confirmation message will be returned.
• If authorization fails, an error message will indicate this. If the service or integration ID is not found, a message specifying the issue will be provided.

Remove an integration connection from a specific uptime monitor by providing both the resource_id and integration_id in the URL path. This action permanently deletes the association, meaning the monitor will no longer send incident data or notifications through that integration channel.

This is useful for keeping your monitoring environment clean and up to date, especially when tools are deprecated, team workflows change, or alert routing needs to be restructured.

Use cases:

• Tool decommissioning — Remove integrations linked to services or platforms that are no longer in use.
• Access control — Disconnect an integration that was configured incorrectly or shared with the wrong recipient.
• Alert cleanup — Simplify notification paths and eliminate unnecessary or duplicate alerting channels.

To modify an integration instead of removing it, use the Update Uptime Monitor Integration endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the integration will be deleted, and a confirmation message will be returned.
• If authorization fails, an error message will indicate the issue. If the specified integration does not exist, a message stating this will be provided.

Register a new server for metric tracking by providing details such as service_id, name, description, and timezone. This endpoint creates a server monitoring resource, allowing you to visualize essential system metrics like CPU, memory, and disk usage through charts.

Once configured, the server will begin reporting usage data to your dashboard, giving your team consistent visibility into system activity across different services and environments.

Use cases:

• Infrastructure setup — Quickly onboard new servers and begin tracking system-level metrics without deep configuration.
• Timezone labeling — Assign a timezone to each server so that metric timestamps in visualizations reflect local server time, improving clarity during reviews.
• Visual trend tracking — View how system resource usage evolves over time to assist in capacity planning or basic diagnostics.
  
  

  Authorization: Bearer YOUR_TOKEN

Delete multiple server monitoring resources in a single request by passing their corresponding monitor_ids as query parameters. This bulk operation is ideal for cleaning up inactive, deprecated, or test servers from your monitoring environment.

It simplifies server management by allowing teams to remove several monitored servers at once instead of deleting them individually.

Use cases:

• Infrastructure cleanup — Remove outdated or unused server entries to keep the monitoring dashboard organized and relevant.
• Environment resets — Clear demo or temporary monitors after staging or testing phases.
• Bulk offboarding — When retiring multiple servers or services, use this endpoint to efficiently decommission their monitors.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified server monitoring resources will be deleted, and a confirmation message along with the IDs of the deleted resources will be returned.
• If the request is unauthorized or the provided IDs are invalid, an error message will be returned, specifying the issue.

Update an existing server monitoring resource by specifying its monitor_id in the path and submitting the new configuration values in the request body. You can modify properties such as the name, description, or timezone to keep the server's metadata up to date.

This endpoint is helpful for maintaining clear and meaningful labels in your monitoring dashboard, especially when server roles change, descriptions need refinement, or timezone alignment improves data readability.

Use cases:

• Rename monitored servers — Keep server names consistent with their real-world purpose or environment.
• Update descriptions — Add context or notes that make it easier to identify monitored systems during troubleshooting.
• Correct timezone configuration — Ensure metric timestamps align with local server time for easier data interpretation.

To view the current details of a server before updating, use the Get Specific Server Monitor endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the server resource will be updated, and a confirmation message along with the updated resource ID will be returned.
• If the request is unauthorized or the provided ID is invalid, an error message will be returned, specifying the issue.

Retrieve a complete list of all server monitoring resources associated with a specific service by providing the service_id in the path. This endpoint returns metadata for each registered server, allowing teams to see which servers are actively being monitored under a given service.

Pagination is supported through the limit and page query parameters, making it easier to manage large infrastructures and avoid overloading responses.

Use cases:

• Monitoring overview — View all servers linked to a service in one place for easy review and filtering.
• Infrastructure audits — Confirm which servers are actively tracked, and identify naming, description, or timezone discrepancies.
• Bulk operations support — Use the returned list to trigger updates, cleanups, or batch actions across monitored servers.

Authorization: Bearer YOUR_TOKEN

Retrieve detailed information about a specific server monitoring resource by providing its monitor_id in the path. The response includes metadata such as the server name, description, timezone, and service association, allowing you to review its current configuration.

This endpoint is helpful for inspecting how a server is registered within your monitoring system before performing updates, deletions, or analysis.

Use cases:

• Pre-update verification — Review server details before applying changes using the Update Server Monitor endpoint.
• Metadata auditing — Validate naming, descriptions, or timezone settings across your monitored infrastructure.
• Troubleshooting support — Identify the specific server configuration when investigating metric charts or alerts.

Authorization: Bearer YOUR_TOKEN

Retrieve time-series metric data for a specific server by providing its monitor_id in the path. This endpoint allows you to query server resource usage — such as CPU, memory, disk, or network — across a specified time window.

You can refine the results using query parameters like type (e.g., cpu, memory), start_date, end_date, interval (e.g., on-demand, hourly), and limit to control the resolution and size of the returned dataset.

Use cases:

• Chart rendering — Populate monitoring dashboards with metric visualizations for a selected server and time period.
• Usage trend analysis — Explore how system resource consumption changes over time to assist with capacity planning.
• Spike investigation — Drill into specific intervals to identify periods of high usage or irregular activity.

Authorization: Bearer YOUR_TOKEN

Create a new heartbeat monitoring resource by providing the required service_id and name in the request body. This resource acts as a check-in point for recurring jobs or processes that are expected to send heartbeat signals at defined intervals.

Once the heartbeat is created, your system or job must send regular requests (pings) to the assigned endpoint. If a ping is missed beyond the expected interval, the monitor will be marked as unhealthy, and an alert can be triggered based on your configuration.

Use cases:

• Background job monitoring — Ensure cron jobs, queue workers, or scheduled scripts are executing on time.
• System health visibility — Detect stalled or silently failed processes before they cause downstream issues.
• Proactive alerting — Receive notifications when heartbeat pings stop, signaling a potential failure or delay.

To send check-ins, use the unique heartbeat endpoint returned in the creation response.

Authorization: Bearer YOUR_TOKEN

Delete multiple heartbeat monitoring resources in a single request by passing their heartbeat_ids as query parameters. This bulk operation is useful when cleaning up unused, test, or deprecated heartbeat monitors from your monitoring system.

It helps keep your workspace organized and ensures that only actively used heartbeats are retained.

Use cases:

• Batch cleanup — Remove several outdated or inactive heartbeat monitors at once to reduce clutter.
• Decommissioning — Clean up heartbeat resources related to retired services or jobs.
• Environment reset — Reset monitoring state between staging, production, or test environments.

To retrieve a list of active heartbeat monitors before deletion, use the Get Heartbeats List endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified heartbeats will be deleted, and a confirmation message along with the IDs of the deleted heartbeats will be returned.
• If the request is unauthorized or the provided IDs are invalid, an error message will be returned, specifying the issue.

Delete a specific heartbeat monitoring resource by providing its heartbeat_id as a path parameter. Once deleted, the associated check-in URL becomes inactive, and no further heartbeat pings will be accepted for that resource.

This operation is useful when decommissioning a job, script, or service that no longer needs monitoring.

Use cases:

• Service retirement — Cleanly remove monitoring for a job or service that has been shut down.
• Test cleanup — Delete temporary heartbeat resources created during development or staging.
• Resource hygiene — Keep your monitoring environment lean by removing obsolete entries.

To view heartbeat monitor before deletion, use the Get Heartbeats Information endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the specified heartbeat will be deleted, and a confirmation message will be returned.
• If the request is invalid or contains invalid parameters, an error message will indicate the issue.

Retrieve all heartbeat monitoring resources associated with a specific service by providing the service_id in the path. This endpoint returns a paginated list of heartbeats, helping you understand which recurring jobs, scripts, or processes are currently being tracked under that service.

Use query parameters such as limit and page to control pagination and manage large sets of heartbeat monitors efficiently.

Use cases:

• Service-level visibility — See all heartbeats linked to a given service for monitoring coverage review.
• Bulk operations — Use the results to prepare for updates or deletions of multiple heartbeat monitors.
• Audit readiness — Verify that all critical background tasks within a service have monitoring in place.

To inspect a specific heartbeat’s details, use the Get Single Heartbeat Monitor endpoint.

Authorization: Bearer YOUR_TOKEN

Update the configuration of an existing heartbeat monitor by providing its heartbeat_id in the path and submitting the updated values in the request body. You can modify fields such as the name or the interval that determines when a missed heartbeat should be treated as a failure.

This operation helps ensure that heartbeat monitors stay aligned with the expected behavior of the processes or systems they track.

Use cases:

• Rename jobs — Update the name of the heartbeat resource to reflect a new job title or function.
• Change incident trigger interval — Update the interval that defines how long the system waits before flagging a missed heartbeat as an incident.
• Reorganize services — Move a heartbeat to a different service context if team responsibilities or architecture shift.

To review a heartbeat's current configuration before updating, use the Get Single Heartbeat Monitor endpoint.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the heartbeat resource will be updated, and a confirmation message will be returned.
• If the request is invalid or cannot be processed, an error message will indicate the issue, such as an invalid URL; if the heartbeat resource is not found, an error will specify that the heartbeat does not exist.

Retrieve detailed information about a specific heartbeat monitor by providing its heartbeat_id in the path. The response includes key details such as the monitor’s name, associated service, interval setting.

This endpoint is useful for reviewing how a heartbeat is configured before updating it or troubleshooting missed signals.

Use cases:

• Configuration review — Check the current settings of a heartbeat monitor before making updates or deletions.
• Audit and visibility — View how a particular job or task is being tracked through heartbeat monitoring.
• Troubleshooting — Inspect the interval and metadata to understand why a heartbeat might be flagged as missed.

To make updates to a heartbeat, use the Update Heartbeat Monitor endpoint.

Authorization: Bearer YOUR_TOKEN

Retrieve time-based execution statistics for a specific heartbeat monitor by providing its heartbeat_id in the path. Use query parameters such as start_date, end_date, and interval to define the time range and level of detail for the data.

The response includes a list of records showing heartbeat activity over time. Each record may contain values such as:

• tick_count — Number of expected heartbeat intervals during that period.
• run_count — Number of actual check-ins (pings) received.
• fail_count — Number of intervals that were missed and counted as failures.
• complete_count — Number of successful intervals (with timely pings).
• received_at — Timestamp of the recorded data point.

Use cases:

• Heartbeat reliability tracking — Identify how consistently a job or service sends heartbeat pings.
• Failure pattern detection — Analyze missed or delayed check-ins across time intervals.
• Monitoring dashboards — Feed data into charts for visualizing heartbeat health over time.

Authorization: Bearer YOUR_TOKEN

Retrieve the full event history for a specific heartbeat monitor by providing its heartbeat_id in the path. This endpoint returns a list of recorded heartbeat events, allowing you to track when check-ins were received and whether they were successful or missed.

You can use query parameters like limit to control the number of results and last_received_at to fetch events after a specific timestamp, which is useful for pagination or incremental analysis.

Use cases:

• Incident analysis — Review missed heartbeats and their timestamps to understand when a job failed to report in.
• System auditing — Verify whether jobs or scripts checked in during critical time windows.
• Monitoring history — Build a timeline of all heartbeat events for visualization or reporting.

Authorization: Bearer YOUR_TOKEN

Submit a heartbeat check-in to signal that a scheduled job or background task has run successfully. To record a new event, provide the heartbeat_id in the path. You can also include an optional result (e.g., success, fail) and a custom message in the request body to describe the event outcome.

Each check-in helps verify that your monitored service is operational and reporting on schedule. If check-ins are not received within the configured interval, the system will automatically mark the heartbeat as failed.

Use cases:

• Automated job reporting — Ping this endpoint from cron jobs, queue workers, or scripts to indicate successful execution.
• Failure tracking — Send a fail result to indicate that a job ran but encountered an issue.
• Operational logging — Include meaningful messages with each event to support debugging and job history reviews.

Retrieve all rulesets configured for your team and organization by calling this endpoint. Each ruleset contains information such as the rule type, name, description, urgency level, and assigned responders (e.g., teams).

The response is grouped into two scopes: team and organisation, showing rules defined at different levels of your environment.

Use cases:

• Ruleset overview — View all active rules that determine how incidents are created from incoming events.
• Responsibility auditing — Check which teams are assigned to respond when a specific rule is triggered.
• Urgency validation — Review urgency settings to ensure incidents are prioritized appropriately based on rule definitions.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will return ruleset data for both team and organization.
• If the request is unauthorized, the system will return an authentication error message.

Create a new ruleset in the incident management system by submitting a configuration payload in the request body. The ruleset defines the logic for automatically generating incidents when specific conditions are met.

Required fields typically include the type of rule (e.g., state-change), an array of conditions, the target team_id or assignees, urgency level, and a descriptive name and description for context.

Once created, this ruleset becomes active and will automatically evaluate incoming events according to the defined logic.

Use cases:

• Proactive alerting — Define custom logic to convert alert data into actionable incidents automatically.
• Team-based triage — Assign rules to specific teams to ensure incidents are routed to the right responders based on the rule's criteria.
• Flexible escalation logic — Configure different urgency levels and descriptions depending on the nature of the matched condition.

To review existing rules, see Get Rulesets.
To delete an existing rule, use Delete Ruleset.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will create a new ruleset and return the ruleset ID.
• If the request is invalid, the system will return an error message with details of the invalid fields.

Update an existing ruleset in the incident management system by providing the ruleset_id in the path and submitting the updated rule configuration in the request body. You can modify fields such as the type of the rule (e.g., state-change), the list of conditions, urgency, description, name, and assigned assignees (e.g., team IDs).

This endpoint is useful for refining how and when incidents are triggered, adjusting team responsibilities, or evolving your alert routing logic as infrastructure or workflows change.

Use cases:

• Policy adjustments — Modify existing rules to reflect updated monitoring logic or operational policies.
• Team ownership changes — Reassign incident ownership by updating team IDs or assignee lists.
• Priority tuning — Adjust urgency levels and descriptions to better align with your response process.

To view current rules, see Get Rulesets.
To create new rules, use Create Ruleset.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will update the ruleset and return a success message.
• If the request is invalid, the system will return an error message with details of the invalid fields.

Delete an existing ruleset from the incident management system by providing its ruleset_id in the path. Once removed, the ruleset will no longer trigger incidents based on its defined conditions.

This is useful for cleaning up deprecated logic, test rules, or automation paths no longer needed in your incident workflows.

Use cases:

• Legacy rules cleanup — Remove rulesets that no longer match your current infrastructure or alerting needs.
• Test configuration removal — Delete temporary rules created during integration or staging setups.

To review or identify rules before deletion, see Get Rulesets.

Authorization: Bearer YOUR_TOKEN

Expected Behavior:

• On success, the system will delete the specified ruleset and return a confirmation message.
• If the request is unauthorized or the ruleset is not found, the system will return an error message.