Skip to main content

Azure Event Hub Sink Node

Quick Reference​

Use Credentials The Azure Event Hub connection to publish through.

Event Hub Name The Event Hub to publish to. ex: my-event-hub

Partition Key Path (optional) JSON path whose value becomes the event's partition key. Events sharing a key land on the same partition and keep their order. ex: $.userId

Encoding Type The output format for each published event.

Overview​

The Azure Event Hub Sink node publishes processed records from your workflow to an Azure Event Hub. Each record is serialized using the selected encoding and sent to the hub, where downstream consumers — other workflows, Azure Stream Analytics, Databricks, or your own applications — can pick it up.

Records are packed into batches automatically. The node fills a batch until it reaches the Event Hub service limit, sends it, and starts a new one, so there is no batch size to tune.

An optional Partition Key Path controls how events spread across the hub's partitions. Left blank, Event Hub distributes events on its own for maximum throughput. Set to a path, all events resolving to the same value go to the same partition and are consumed in order relative to each other.

Configuration​

FieldDescriptionRequiredDefault
Use CredentialsSelect or create an Azure Event Hub connection. It supplies the namespace connection string, or the Entra ID identity used to authenticate.Yes—
Event Hub NameThe name of the Event Hub to publish to (e.g. my-event-hub).Yes—
Partition Key PathJSON path to the field whose value becomes the event's partition key (e.g. $.userId). Leave blank to let Event Hub distribute events across partitions.No—
Encoding TypeThe format each record is serialized to. Options: CSV, JSON Object, JSON Array, JSON Lines. More info here.YesJSON Object

Choosing a Partition Key​

A partition key is worth setting when consumers need related events in order — all events for one device, one user, or one order processed in sequence.

Pick a field with many distinct values. Partition keys are hashed onto partitions, so a low-cardinality key (a status flag, a region with three values) concentrates all traffic onto a few partitions and caps throughput. A high-cardinality identifier like a device or user id spreads load evenly.

Records whose path resolves to nothing are treated as having no key and are distributed normally.

Notes​

Oversized records are dropped, not retried. A single record too large to fit in an empty Event Hub batch cannot be sent and is reported as an error for that record. The rest of the batch is unaffected.

Serialization errors are isolated. A record that fails to serialize is reported individually; the remaining records in the batch are still published.