Skip to main content

Available Endpoints

Jetstream v2 is served on the same endpoints as v1 — there is no separate host. The JetstreamV2 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.
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 the x-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 — download jetstream_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-chosen filter_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 increasing sequence number (per stream) so clients can detect gaps. Exactly one payload is set.

Filter Validation

After each AddFilters / RemoveFilters, the server returns one FilterResult per filter, acknowledging acceptance or explaining the rejection.

Heartbeat

Filtered Transaction

Each matched transaction lists the filter_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:
  1. Generate client code from the jetstream.v2 definition above.
  2. Open the SubscribeTransactions bidirectional stream and authenticate (x-token header or IP whitelist).
  3. Send an AddFilters request with one or more TxFilter entries, each with a unique filter_id.
  4. Read the FilterResult acknowledgements, then the stream of FilteredTransaction messages.
  5. Add or remove filters at any time without reopening the stream.
  6. Track sequence to detect gaps, and treat a connection close as a signal to reconnect.
  7. Optionally open SubscribeSlots (a separate stream) for slot lifecycle events.

Code Generation

For TypeScript/JavaScript:
For Rust:

Best Practices

  1. Filtering
    • Always set at least one account constraint; empty filters are rejected.
    • Use a stable, unique filter_id per filter so you can correlate matches and remove filters later.
  2. Enrichment
    • Leave include_enrichment off 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.
  3. Sequence & Reconnection
    • Track the sequence number to detect dropped messages.
    • Implement automatic reconnection; on reconnect, re-send your AddFilters.
  4. Liveness
    • Use Heartbeat and Ping/Pong to confirm the stream is healthy and measure latency.

See Also

Jetstream v2 Overview

What v2 adds over v1, the streaming model, and getting started.

Jetstream (v1) Reference

The v1 Protocol Buffer specification.

Support

For technical questions about the v2 protocol or implementation details, please join our Discord community.