Reference · built on requestConnectorStreams, queues & webhooks

Azure Event Hubs

Partitioned event streams from Azure Event Hubs, read over AMQP 1.0 or Kafka in a consumer group and sent by HTTPS POST.

Request accessPricing ↗

About

Azure Event Hubs is Microsoft's event ingestion service. A namespace holds event hubs; each event hub is an append-only log split into partitions, and a partition key keeps related events together in order. Consumers read through consumer groups, each with its own position, over AMQP 1.0 or the Kafka protocol, and save their offsets as checkpoints. Retention is time-based, and Capture writes older events to Blob Storage or Data Lake Storage.

Through Fibric, the connector reads each partition in a consumer group reserved for it and hands the events to an operator, which proposes what should change. Sending is rare and always approved first: one HTTPS POST or AMQP send per decision, with a receipt.

This is a reference listing. It documents what Fibric would read from Azure Event Hubs and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Events on each partition, read over AMQP 1.0 or the Kafka protocol, with body, offset, sequence number, user properties, and enqueue time
  • The $Default consumer group and any consumer group created for the connector, each tracking its own position in the stream
  • Offsets and checkpoints the consumer stores in Azure Blob Storage, one container per consumer group
  • Avro or Parquet files that Event Hubs Capture writes to Blob Storage or Data Lake Storage
  • Namespaces, event hubs, consumer groups, and authorization rules through the Microsoft.EventHub Resource Manager API

Proposed actions

  • Target capability: propose sending an event or batch by HTTPS POST to https://{namespace}.servicebus.windows.net/{eventHubPath}/messages, or over AMQP 1.0
  • Target capability: propose a partition key on outbound events so related events land on one partition in order
  • Target capability: propose creating a consumer group for the connector through the Resource Manager API

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Read device telemetry in a group of your own

    A consumer group reserved for the operator reads the same partitions as your other consumers without contending with them. It checkpoints offsets to Blob Storage and resumes from the last checkpoint after a restart.

    With Sensor Health

  • Catch a cold-chain excursion in the stream

    Temperature events partitioned by device key arrive in order. The operator follows each device's stream, notices a reading outside range, and proposes a hold on the affected lot for your approval.

    With Cold Chain Excursion

  • Prove the stream is still flowing

    The operator compares the enqueue time of the last event on each partition with the clock and proposes a notice when a partition goes quiet longer than its usual gap.

    With Data Freshness, Integration Health

Requirements

  • An Event Hubs namespace on the Standard, Premium, or Dedicated tier; Basic allows one consumer group and one day of retention
  • A consumer group for the connector: Standard allows 20 per event hub, Premium 100, Dedicated 1,000
  • An Azure Storage account and container for checkpoints in the connector's region, with hierarchical namespace, soft delete, and versioning disabled
  • Network reach to {namespace}.servicebus.windows.net, directly or through Private Link on Standard tier and above
  • An Entra role assignment or a SAS policy with listen rights scoped to the event hub
Authentication
Microsoft Entra ID OAuth 2.0 with the Azure Event Hubs Data Receiver or Data Sender role, or a Shared Access Signature from a policy with listen or send rights, in the Authorization header.

Limits

  • A publication, single event or batch, is at most 1 MB on Standard and Premium, 256 KB on Basic, and 20 MB on Dedicated.
  • Retention is up to 7 days on Standard and 90 days on Premium and Dedicated; events cannot be deleted before they expire.
  • HTTPS can send but not receive. Reading needs AMQP 1.0 or Kafka; at most 5 non-epoch receivers may share a partition per consumer group.
  • Each throughput unit on Standard allows 1 MB/s or 1,000 events per second in and 2 MB/s or 4,096 events per second out.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Azure Event Hubs ↗

Questions and answers

Can this connector read events over HTTPS?
No. Event Hubs supports HTTPS for sending only. The connector reads over AMQP 1.0 or the Kafka protocol in its own consumer group and checkpoints its offsets to Blob Storage so it can resume where it stopped.
How far back can the operator read?
As far as the event hub's retention: up to 7 days on Standard, 90 days on Premium and Dedicated. A consumer can start from an offset, a timestamp, or the beginning or end of the stream. Anything older must come from Event Hubs Capture files.
Will the connector disturb my existing consumers?
Not if it has its own consumer group; each group keeps an independent position. Within one group, an epoch consumer with a higher owner level disconnects the current owner of a partition, so the connector must not share a group with another reader.
Ask about Azure Event Hubs

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Azure Event Hubs through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy