Subscription

Stream over gRPC (or gRPC-web) from the same Yellowstone target you query against. The token rides as the x-token metadata header on the call; see Authentication.

https://yellowstone.raptor.trade
# grpc target: yellowstone.raptor.trade:443
# auth header: x-token: $RAPTOR_TOKEN

connect → subscribe → hydrate → live changes → unsubscribe

A SubscribeMethod call is server-streaming: it takes the MethodRequest you would query with - a method path and a JSON params string carrying the selector plus hydrate, throttle, and linger - and returns a stream of SubscribeUpdate messages. The first updates replay up to hydrate recent data; every change after that arrives on the same stream.

grpcurl -H "x-token: $RAPTOR_TOKEN" \
  -d '{
    "method": "solana::market::ohlcv",
    "params": "{\"base\":\"So11111111111111111111111111111111111111112\",\"window\":\"1m\",\"hydrate\":50,\"throttle\":\"1s\"}"
  }' \
  yellowstone.raptor.trade:443 geyser.Geyser/SubscribeMethod

Each SubscribeUpdate wraps a Row: its columns, the label that echoes your request, an id, and a change_kind of INSERT, UPDATE, or DELETE. The TypeScript SDK routes by kind to on_insert, on_update, and on_delete; the Rust SDK yields an Event carrying the kind and decoded row. Apply inserts as new rows and reconcile updates and deletes against rows you hold by id.

Three optional parameters shape what a subscription delivers and how often. Over SubscribeMethod they sit inside the params JSON; over SubscribeRql they are top-level request fields.

On subscribe the server replays up to hydrate most-recent data as the first inserts, so you start with state rather than an empty view. Set it to 1 if you only want changes from now on. Values above 100 are clamped to 100, and 0 is raised to 1.

The server coalesces changes within each throttle interval so a busy market never floods the stream. A duration is an integer plus a unit: 500ms, 2s, 15m. Because changes are batched, a single update can carry several data points of the same kind.

linger is a short window the server waits after the first change before it sends a frame, so near-simultaneous changes ride together instead of as separate updates. It defaults to 20ms; set 0ms to forward each change as soon as it is ready.

When you want to write the query yourself, SubscribeRql takes an RQL string under a label and streams the same updates. This is the escape hatch the method + params surface is built on; the label is echoed back on every data point.

grpcurl -H "x-token: $RAPTOR_TOKEN" \
  -d '{
    "rql": { "candles": "from solana::market::ohlcv::1m | take { 50 }" },
    "hydrate": 50,
    "throttle": "1s"
  }' \
  yellowstone.raptor.trade:443 geyser.Geyser/SubscribeRql

Call sub.unsubscribe() to stop. Unlike the WebSocket SDK, it is synchronous - it aborts the underlying gRPC stream rather than sending an unsubscribe message.

A bad subscribe - an invalid base or an unknown window, say - comes back as a gRPC Status that ends the stream. The TypeScript SDK has no error callback; the failure propagates out of the background subscribe loop as an unhandled promise rejection. The Rust stream yields it as the next Err item. See Errors for the codes.