Kafka via Chain Sink

Kafka is not a target type you create directly, the way webhook and websocket are. To land events on a Kafka topic, run Chain Sink with its kafka adapter enabled. Chain Sink consumes the WebSocket stream on your behalf and produces each message, unmodified, to the topic you configure.

When to use this

If you already have Kafka-based infrastructure and want Event Streaming data to show up as just another topic, this is the path. If you only need one consumer, a direct WebSocket connection is simpler and has one fewer moving part.

How it works

graph LR
    A[Event Streaming - WebSocket] --> B[Chain Sink]
    B --> C[Kafka adapter]
    C --> D[Your Kafka topic]

1. Create a WebSocket target the same way as for direct WebSocket consumption, with rules and variables pointed at it as usual.
2. Run Chain Sink configured with adapter.type: kafka, pointed at that target's WebSocket URL.
3. Chain Sink forwards each event it receives to the Kafka brokers and topic in its config, as the raw bytes received over the WebSocket connection — the same ALL_DATA, UNIFIED_V1, or UNIFIED_V1_RAW envelope reaches your topic untouched.

Minimal Chain Sink config for Kafka

stream:
  url: "wss://svc.blockdaemon.com/streaming/v2/targets/<target_id>/websocket"
  api_key: "<API_KEY>"
  mode: "noack"

adapter:
  type: "kafka"
  kafka:
    producer:
      brokers: ["localhost:9092"]
      topic: "chain-events"

When connecting through Chain Sink, the API key is sent as an x-api-key header, not Authorization: Bearer — that's different from a direct WebSocket connection made without Chain Sink, and worth checking first if auth fails.

See Chain Sink for the full configuration reference, including ack mode and custom headers.

Topic creation

Chain Sink creates the destination Kafka topic automatically if it doesn't already exist. Once the WebSocket connection and adapter are live, events start landing on the topic right away.

Delivery and failure behavior

Chain Sink does not add its own buffering, retry limit, or dead-letter queue on top of the WebSocket connection. If the Kafka adapter can't deliver a message, the failure is logged, and actual delivery resilience falls back to the Kafka client's own producer-level retry behavior rather than anything Chain Sink implements itself. In ack mode, a failed handoff to the adapter means no acknowledgment is sent for that message, and Blockdaemon treats it as undelivered — see Chain Sink: Failure handling.