This document explains how to use HTTP API for setting up and consuming persistent subscriptions and competing consumer subscription groups. For an overview on competing consumers and how they relate to other subscription types please see our getting started guide.
Tips
The Administration UI includes a Competing Consumers section where you are able to create, update, delete and view subscriptions and their statuses.
Before interacting with a subscription group, you need to create one. You receive an error if you try to create a subscription group more than once. This requires admin permissions.
Persistent subscriptions to $all are not supported over the HTTP API. If you want to create persistent subscriptions to $all, the gRPC client should be used instead. :::
You can edit the settings of an existing subscription while it is running. This drops the current subscribers and resets the subscription internally. This requires admin permissions.
URI
Supported Content Types
Method
/subscriptions/{stream}/{subscription_name}
application/json
POST
Persistent subscriptions to $all are not supported over the HTTP API. If you want to update persistent subscriptions to $all, the gRPC client should be used instead. :::
Deleting persistent subscriptions to $all is not supported over the HTTP API. If you want to delete persistent subscriptions to $all, the gRPC client should be used instead. :::
By default, reading a stream via a persistent subscription returns a single event per request and does not embed the event properties as part of the response.
Persistent subscriptions to $all are not supported over the HTTP API. If you want to read events via a persistent subscriptions to $all, the gRPC client should be used instead. :::
Clients must acknowledge (or not acknowledge) messages in the competing consumer model. If the client fails to respond in the given timeout period, the message is retried. You should use the rel links in the feed for acknowledgements not bookmark URIs as they are subject to change in future versions.