Available Endpoints
Jetstream v2 is served on the same endpoints as v1 — there is no separate host. TheJetstreamV2
service is exposed over the same HTTP/2 connection and routed by the gRPC method path, so you connect
to the region closest to your infrastructure exactly as you would for v1.
- US
- Europe
- Asia Pacific
Jetstream uses plain
http:// (not https://) for gRPC connections. gRPC negotiates its own
transport security over HTTP/2. Use https:// only if your dedicated node explicitly requires it.Authentication
Authentication is the same as v1: supply your API key in thex-token gRPC metadata header, or use
IP-whitelist authentication. See Authentication for details.
Protocol Buffer Specification
This document outlines the Protocol Buffer (protobuf) specification used by OrbitFlare Jetstream v2. The complete specification can be found in our GitHub repository — downloadjetstream_v2.proto there to generate your client, or use the definition reproduced below.
The jetstream.v2 package is fully independent of v1 — generate a separate client from it.
Service Definition
Request Messages
SubscribeTransactions is a bidirectional stream. The client sends a sequence of request messages —
each carrying exactly one payload — to manage its subscription while the stream is open.
SubscribeTransactionsRequest
Adding Filters
Filters are added dynamically while the stream is open. Each filter carries a client-chosenfilter_id that is echoed back on every matching transaction and in the validation acknowledgement.
A filter must specify at least one of
account_include / account_exclude / account_required.
Empty (match-everything) filters are rejected — see FilterResult.Removing Filters
Response Messages
SubscribeTransactionsResponse
Every message on the stream carries a server timestamp and a monotonically increasingsequence
number (per stream) so clients can detect gaps. Exactly one payload is set.
Filter Validation
After eachAddFilters / RemoveFilters, the server returns one FilterResult per filter,
acknowledging acceptance or explaining the rejection.
Heartbeat
Filtered Transaction
Each matched transaction lists thefilter_id values it matched, followed by the transaction itself.
Shared Types
Slot Streaming
SubscribeSlots is a server stream of slot lifecycle events. It takes no parameters — open the stream
and receive events as slots progress.
Non-streaming Methods
Using the Protocol
A typical v2 client:- Generate client code from the
jetstream.v2definition above. - Open the
SubscribeTransactionsbidirectional stream and authenticate (x-tokenheader or IP whitelist). - Send an
AddFiltersrequest with one or moreTxFilterentries, each with a uniquefilter_id. - Read the
FilterResultacknowledgements, then the stream ofFilteredTransactionmessages. - Add or remove filters at any time without reopening the stream.
- Track
sequenceto detect gaps, and treat a connection close as a signal to reconnect. - Optionally open
SubscribeSlots(a separate stream) for slot lifecycle events.
Code Generation
For TypeScript/JavaScript:Best Practices
-
Filtering
- Always set at least one account constraint; empty filters are rejected.
- Use a stable, unique
filter_idper filter so you can correlate matches and remove filters later.
-
Enrichment
- Leave
include_enrichmentoff unless you need the extra fields — lean output is smaller. Enabling it adds no latency; the only cost is a modestly larger message. - Enrichment is subscription-wide: enabling it on any one filter enriches every transaction the session receives.
- Leave
-
Sequence & Reconnection
- Track the
sequencenumber to detect dropped messages. - Implement automatic reconnection; on reconnect, re-send your
AddFilters.
- Track the
-
Liveness
- Use
HeartbeatandPing/Pongto confirm the stream is healthy and measure latency.
- Use
See Also
Jetstream v2 Overview
What v2 adds over v1, the streaming model, and getting started.
Jetstream (v1) Reference
The v1 Protocol Buffer specification.