Delete link

delete/v2/environments/{environmentId}/alertLinks/{alertLinkId}

Page View

Alert endpoints allow you to review or manage traffic alert rules, which monitor your integrations for healthy traffic. Learn about alerts.

There are two types of traffic alert rules: No Traffic or Error Threshold.

Alert rule definitions

A No Traffic alert rule monitors whether traffic is flowing appropriately in a given subscription. For this type of alert, we send a notification if no logs reach a terminal state (i.e., Succeeded, Filtered, or Failed) in a specified amount of time (i.e., as little as 30 minutes up to 72 hours). Since pending logs don't count as completed traffic, pending traffic could be a condition you define to trigger an alert. Failed logs do count as completed traffic, so this type of alert isn't for tracking errors.

An Error Threshold rule monitors the number of errors in a given subscription. This type of alert rule triggers a notification if X number of logs reach a terminal state of Failed and will no longer be retried within a specified time (i.e., as little as 15 minutes up to 24 hours).

You can retrieve an alert rule, as well as create, update, or delete it. Alternatively, you can retrieve a list of alert rules. An alert rule response contains details about any related subscription links.

You can also retrieve a subscription link for an alert rule, as well as create, pause, or delete it.

Delete link

Delete an existing subscription link for an alert rule within a Redox organization.

Only for engineer or support roles

Any user in an environment may view alert rules and alert history. However, you must be assigned to an engineer or a support role to manage alerts. Learn about roles.

Alert rules aren't available for free Redox accounts, so they won't be visible in the dashboard or available via API. You must upgrade your Redox account to use alert rules.

Request parameters and payload

cURL request example

bash

1
curl 'https://api.redoxengine.com/platform/v2/environments/{environmentId}/alertLinks/{alertLinkId}' \
2
--request DELETE \
3
--header 'Authorization: Bearer $API_TOKEN' \
4
--header 'accept: application/json'

Path Parameters

environmentId
required, string
Identifies the specific environment that you're operating in or on behalf of.
alertLinkId
required, string
Contains the unique identifier of the alert link.

Response fields and example

Example payload generated from schema

1
{
2
  "meta": {
3
    "version": "1.0.0"
4
  },
5
  "payload": {
6
    "message": "string"
7
  }
8
}

Describes the outcome of the delete request.

meta
object
- version
  string
  Lists the major and minor version number for the format of the returned payload. The payload format or shape may change between minor versions, like including additional or extended fields in later versions. We include the version data in each response so that you have the option to handle the signaled differences.
payload
object
- message
  string
  Explains that the delete request was successful, so the alert link no longer exists. This action doesn't delete the related alert; any related alerts but be explicitly deleted with the "Delete alert" endpoint.

FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.