Skip to main content
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Data Days is here! Join us now for 60+ days of learning, challenges, and connection. Learn more

svelde

Add HTTP REST / Webhook source and destination to Eventstream

Submitted by Super User on ‎05-18-2025 02:43 PM

At this moment, Eventstream has no support for ingesting messages via HTTP REST / Webhook (like an Azure Function HTTP trigger).

 

The same goes for egress to an HTTP REST / Webhook endpoint.

 

Supporting these endpoints opens many possibilities to integrate directly with external platforms, in real-time.

 

 

Status: Under Review
See more ideas labeled with:
5 Comments (5 New)
Comments
svelde
Super User
Super User
‎05-18-2025 03:17 PM
As a source, offer both consuming a 3rd party endpoint (where the Eventstream pulls data from) and providing an endpoint where 3rd party solutions push data to. That last variant should act like an HTTP-triggered function.
arindamc
Microsoft Employee
Microsoft Employee
‎07-11-2025 11:14 PM
Status changed to: Under Review
 
alexlzx
Microsoft Employee
Microsoft Employee
‎07-23-2025 02:04 AM

Thanks for your suggestion to add HTTP REST / Webhook support to Eventstream. It’s a valuable idea for enabling real-time integration with external platforms.

 

To confirm, are you looking for the following capabilities?

  1. HTTP source (pull-based): Eventstream continuously pulls data from external HTTP endpoints.
  2. HTTP source (push-based): Eventstream acts as a webhook receiver, allowing external platforms to send HTTP POSTs or other requests to it.
  3. HTTP destination: Eventstream sends data to external systems via HTTP.

 

Let us know if this matches your request, or if there are specific platforms or use cases you’d like us to consider.

svelde
Super User
Super User
‎07-25-2025 04:28 AM
Yes, all three are useful. Regarding pulling data from a source (eg. time based) is perfect. This can lead to duplicates but this can be fixed using eg. Eventhouse materialized view. Allowing some control over the query properties would be helpful eg. the datetime of the LAST successful call. I can think of more elaborate scenarios (like a datetime from the last row from the previous message body indicating the latest messages received at that moment so no messages are missed).
svelde
Super User
Super User
‎03-23-2026 01:42 PM
See also this Fabric community discussion: https://community.fabric.microsoft.com/t5/Eventstream/Options-for-High-Frequency-Low-Latency-API-Ing... There dynamic behaviour is expected so the latest call starts where the previous one ended via a (timestamp) parameter. This way, gaps in ingestion or overlap or an ingestion overload (when a burst of data is provided) can be prevented.