JetStream wire API Reference
The normal way to use JetStream is through the NATS client libraries which expose a set of JetStream functions that you can use directly in your programs. But that is not the only way you can interact with the JetStream infrastructure programmatically. Just like core NATS has a wire protocol on top of TCP, the JetStream enabled nats-server(s) expose a set of Services over core NATS.
Reference
All of these subjects are found as constants in the NATS Server source, so for example the subject $JS.API.STREAM.LIST
is represented by api.JSApiStreamList
constant in the nats-server source. Tables below will reference these constants and payload related data structures.
Note that if the resources you're trying to access have a JetStream domain associated with them, then the subject prefix will be $JS.{domain}.API
rather than $JS.API
.
Error Handling
The APIs used for administrative tools all respond with standardised JSON and these include errors.
Here the responses include a type
which can be used to find the JSON Schema for each response.
Non admin APIs - like those for adding a message to the stream will respond with -ERR
or +OK
with an optional reason after.
Admin API
All the admin actions the nats
CLI can do falls in the sections below. The API structure are kept in the api
package in the jsm.go
repository.
Subjects that end in T
like api.JSApiConsumerCreateT
are formats and would need to have the Stream Name and in some cases also the Consumer name interpolated into them. In this case t := fmt.Sprintf(api.JSApiConsumerCreateT, streamName)
to get the final subject.
The command nats events
will show you an audit log of all API access events which includes the full content of each admin request, use this to view the structure of messages the nats
command sends.
The API uses JSON for inputs and outputs, all the responses are typed using a type
field which indicates their Schema. A JSON Schema repository can be found in nats-io/jsm.go/schemas
.
General Info
Subject | Constant | Description | Request Payload | Response Payload |
---|---|---|---|---|
|
| Retrieves stats and limits about your account | empty payload |
|
Streams
Subject | Constant | Description | Request Payload | Response Payload |
---|---|---|---|---|
|
| Paged list known Streams including all their current information |
|
|
|
| Paged list of Streams |
|
|
|
| Creates a new Stream |
|
|
|
| Updates an existing Stream with new config |
|
|
|
| Information about config and state of a Stream | empty payload, Stream name in subject |
|
|
| Deletes a Stream and all its data | empty payload, Stream name in subject |
|
|
| Purges all of the data in a Stream, leaves the Stream | empty payload, Stream name in subject |
|
|
| Deletes a specific message in the Stream by sequence, useful for GDPR compliance |
|
|
|
| Retrieves a specific message from the stream |
|
|
|
| Initiates a streaming backup of a streams data |
|
|
|
| Initiates a streaming restore of a stream |
|
|
Consumers
Subject | Constant | Description | Request Payload | Response Payload |
---|---|---|---|---|
|
| Create an ephemeral consumer |
|
|
|
| Create a consumer |
|
|
|
| Create a consumer (server 2.9+) |
|
|
|
| Paged list of known consumers including their current info for a given stream |
|
|
|
| Paged list of known consumer names for a given stream |
|
|
|
| Information about a specific consumer by name | empty payload |
|
|
| Deletes a Consumer | empty payload |
|
| N/A | Consumer to subscriber flow control replies for | empty payload | reply subject |
| N/A | Acknowledgments for | empty payload | reply subject |
ACLs
When using the subjects based ACL please note the patterns in the subjects grouped by purpose below.
General information
Stream Admin
Consumer Admin
Consumer message flow
Optional Events and Advisories :
This design allows you to easily create ACL rules that limit users to a specific Stream or Consumer and to specific verbs for administration purposes. For ensuring only the receiver of a message can Ack it we have response permissions ensuring you can only Publish to Response subject for messages you received.
Acknowledging Messages
Messages that need acknowledgement will have a Reply subject set, something like $JS.ACK.ORDERS.test.1.2.2
, this is the prefix defined in api.JetStreamAckPre
followed by <stream>.<consumer>.<delivered count>.<stream sequence>.<consumer sequence>.<timestamp>.<pending messages>
.
JetStream and the consumer (including sourced and mirrored streams) may exchange flow control messages. A message with the header: NATS/1.0 100 FlowControl Request
must be replied to, otherwise the consumer may stall. The reply subjects looks like: $JS.FC.orders.6i5h0GiQ.ep3Y
In all of the Synadia maintained API's you can simply do msg.Respond(nil)
(or language equivalent) which will send nil to the reply subject.
Fetching The Next Message From a Pull-based Consumer
If you have a pull-based Consumer you can send a standard NATS Request to $JS.API.CONSUMER.MSG.NEXT.<stream>.<consumer>
, here the format is defined in api.JetStreamRequestNextT
and requires populating using fmt.Sprintf()
.
Here we ask for just 1 message - nats req
only shows 1 - but you can fetch a batch of messages by varying the argument. This combines well with the AckAll
Ack policy.
The above request for the next message will stay in the server for as long as the client is connected and future pulls from the same client will accumulate on the server, meaning if you ask for 1 message 100 times and 1000 messages arrive you'll get sent 100 messages not 1.
This is often not desired, pull consumers support a mode where a JSON document is sent describing the pull request.
This requests 10 messages and asks the server to keep this request for 7 seconds, this is useful when you poll the server frequently and do not want the pull requests to accumulate on the server. Set the expire time to now + your poll frequency.
Here we see a second format of the Pull request that will not store the request on the queue at all but when there are no messages to deliver will send a nil bytes message with a Status
header of 404
, this way you can know when you reached the end of the stream for example. A 409
is returned if the Consumer has reached MaxAckPending
limits.
Fetching From a Stream By Sequence
If you know the Stream sequence of a message you can fetch it directly, this does not support acks. Do a Request() to $JS.API.STREAM.MSG.GET.ORDERS
sending it the message sequence as payload. Here the prefix is defined in api.JetStreamMsgBySeqT
which also requires populating using fmt.Sprintf()
.
The Subject shows where the message was received, Data is base64 encoded and Time is when it was received.
Consumer Samples
Samples are published to a specific subject per Consumer, something like $JS.EVENT.METRIC.CONSUMER_ACK.<stream>.<consumer>
you can just subscribe to that and get api.ConsumerAckMetric
messages in JSON format. The prefix is defined in api.JetStreamMetricConsumerAckPre
.
Last updated