The single GraphQL-over-WebSocket channel exposed by Bitquery. All subscription operations (DEX trades, transfers, blocks, transactions, mempool transactions, contract events, balance updates, etc.) are multiplexed over this one channel using GraphQL protocol envelopes. The actual data shape is determined by the GraphQL document sent in the `subscribe` (or `start`) message payload.
First frame the client sends after the WebSocket opens.
Content-Type:
subscribe
Starts a new GraphQL subscription, identified by `id`.
Content-Type:
start
Legacy `subscriptions-transport-ws` form of `subscribe`. Identical payload, different `type`.
Content-Type:
ping
Optional ping frame.
Content-Type:
complete
Terminates a single subscription identified by `id`. Sent by the server when the subscription naturally ends or by the client to stop it. Bitquery does not acknowledge legacy `stop` messages, so clien
Content-Type:
connection_ack
Server acknowledgement that the connection is initialised.
Content-Type:
next
A subscription result pushed to the client.
Content-Type:
data
Legacy form of `next`.
Content-Type:
ka
Periodic keep-alive frame the server emits on the `graphql-ws` subprotocol so clients can detect a silent disconnect.
Content-Type:
pong
Pong frame, emitted in response to a `ping` or as a heartbeat to keep the connection alive on the `graphql-transport-ws` subprotocol.
Content-Type:
error
Subscription-scoped GraphQL error frame.
Content-Type:
About AsyncAPI
The AsyncAPI specification describes event-driven APIs the way OpenAPI describes request/response APIs. A channel is the named pipe — a webhook URL, a Kafka topic, a WebSocket route, an MQTT subject — that producers and consumers publish or subscribe to. Each channel carries one or more messages with structured payloads, and an operation declares whether a given party sends or receives on that channel.