Create subscription

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Name of the subscription. This is used for easy, human readable identification of the subscription.

The topic that updates should be sent for.

Filter the updates using a subset of the Kibana Query Language. The field names that you use in your filter must exactly match the field names on the object that you are filtering. There are some limitations to the filters that you can use:

1. Filters can only be on top-level fields that are included in the filterable_fields property of the topic.
2. Filters cannot be on fields that are an array or dictionary.
3. Filters only support AND clauses (not OR).

If you do not provide any filter, all updates on the topic will be sent to the target.

Some examples:

• If you are interested in all updates on an asset with id of 1234, you can use id:1234.
• If you are interested in all updates on an asset with id of 1234 and type of ASSET_TYPE_VIDEO (which is an enum), you can use id:1234 AND type:ASSET_TYPE_VIDEO.
• If you are interested in all updates on an entity with type team and name of Barcelona, you can use type:team AND name:Barcelona.
• If you are interested in all updates where a field value is after a certain date or time, you can use field_name>"2006-01-02 15:04:05" (in that specific format, specified in UTC).

If a filter cannot be parsed or is invalid, the subscription may still pass initial validation but will then be ignored at run-time, meaning you will not receive any updates as they come through. Be sure to test your filters before relying on them in a production environment.

URL to which the events should be sent.

If true, the subscription will be deleted after the first use. This is useful for cases where the the callback is meant to update the state change of a single resource, e.g. to continue a workflow when a dependent resource is ready.

Subscription is used to define which events of the relevant topics should be sent to the callback URL. Limitations:

1. This is only forward-looking, meaning that only events that occur after the subscription is created will be sent to the target.
2. There may only be two (2) subscriptions per topic, unless the subscription filter specifies a specific id field OR delete_after_use is set to true.
3. Delivery is not guaranteed; message delivery will be retried when encountering a non-2xx response, but if there are multiple subscriptions for the same topic and one subscription successfully received the message, it will not be redelivered to the others.