Skip to main content
GET
GET /v1/events/subscriptions

List and Retrieve Alerts

List alerts, retrieve one, look up the available sources, filters, and triggers, and inspect what an alert has delivered.

List Alerts

List the alerts in your OpenMetadata instance, optionally filtered by alert type, with GET /v1/events/subscriptions.
string
Return only alerts of this type: Notification or Observability.
string
Comma-separated list of fields to include. Supported values: owners, filteringRules.
integer
default:"10"
Number of alerts to return in one page.
string
Cursor for the previous page.
string
Cursor for the next page.

Retrieve an Alert

Retrieve one alert by ID or by name.
  • By ID: GET /v1/events/subscriptions/{id}
  • By name: GET /v1/events/subscriptions/name/{name}
Both accept the fields query parameter.
GET /v1/events/subscriptions

Available Sources, Filters, and Triggers

Ask what a set of sources supports with POST /v1/events/subscriptions/capabilities. OpenMetadata applies the same rules when you create the alert, so use the answer to build a valid request for Create an Alert.
string
required
Observability or Notification.
array
Names of the sources you plan to use. Leave it empty to list every source of the alert type.
object
The filters and triggers chosen so far, in the same shape as the alert’s input. With it, the response warns about any selected source that none of the chosen triggers applies to.
Each source has one of three kinds:
  • entity: changes to one asset type, such as table or pipeline. Every Observability source is an entity source.
  • activity: the collaboration items announcement, conversation, and task.
  • all: every event.
An alert combines sources of one kind only, and all can’t be combined with other sources. A request that breaks either rule returns a 400 error that names the rule. This request asks about an alert on pipelines and ingestion pipelines that has one trigger:
The response has these fields:
  • sources: every source of the alert type. Each has a name, a kind, and a selected flag. A source you can’t add to the selection has canJoin: false and a reason. A selected source that can never produce a match has a warning, but the alert still saves.
  • filters: the filters every selected source supports. Each item has the filter in condition and the sources it applies to.
  • triggers: the triggers at least one selected source supports. Each item has the trigger in condition and the sources it applies to.
  • containerEntities: the entity types a name filter can be scoped to.
  • eventTypes: the event types the selected sources emit.
  • recipientCategories: who inside OpenMetadata the alert can be sent to, such as Owners or Admins.
In this shortened response, the chosen trigger applies only to pipeline, so ingestionPipeline has a warning. To clear it, add the ingestion pipeline trigger as well.
GET /v1/events/subscriptions/{alertType}/resources still works, but it’s deprecated and will be removed in a future release. It describes each source on its own, so it can’t tell you what several sources support together. Its responses include a Deprecation header and a Link header that points to the capabilities endpoint.

Events and Delivery Status

Use these endpoints to see what an alert has processed and delivered. They require view access to all alerts. The {id} and {name} forms behave the same. OpenMetadata keeps these records for the retention period set in the Data Retention application. The default is 7 days.

Response

Each alert includes these fields:
  • id, name, and fullyQualifiedName
  • alertType and enabled
  • resources, input, and destinations
  • filteringRules: the filters and triggers as expanded conditions, returned when you request it with fields
  • pollInterval, batchSize, and retries
  • version, updatedAt, and updatedBy