Add HTTP REST / Webhook source and destination to Eventstream
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.
6 Comments
- sveldeSuper UserAs 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.
- arindamcMicrosoft EmployeeStatus changed:NewtoUnder Review
- alexlzxMicrosoft Employee
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?
- HTTP source (pull-based): Eventstream continuously pulls data from external HTTP endpoints.
- HTTP source (push-based): Eventstream acts as a webhook receiver, allowing external platforms to send HTTP POSTs or other requests to it.
- 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.
- sveldeSuper UserYes, 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).
- sveldeSuper UserSee also this Fabric community discussion: https://community.fabric.microsoft.com/t5/Eventstream/Options-for-High-Frequency-Low-Latency-API-Ingestion/m-p/5136740#M770 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.
- arindamcMicrosoft EmployeeStatus changed:Under ReviewtoCompleted
The HTTP / REST API source for Eventstream feature is now available: HTTP Source in Fabric Eventstream - Microsoft Fabric | Microsoft Learn. Marking idea as "Completed". Please feel free to open up new ideas to track the Webhook source/destination feature.
Recent ideas
Enable Ownership Change / Take‑Over for Mirrored Database Items in Fabric
Mirrored DBs do not support ownership transfer today. This becomes an issue when someone leaves the company. And the user tied to the ownership is beeing disabled. That means you need to recreate the...Sigurd2 hours agoNew MemberNew828Views22likes2CommentsAmazon Redshift Connector - Power query
Amazon Redshift is a supported connector within Power Query and supports Microsoft Entra ID (Azure AD) Single Sign-On (SSO) scenarios through Power BI Service and Power BI semantic models. Documentat...aashraysood2 hours agoMicrosoft EmployeeNew3Views0likes0CommentsAPI to check that Failure Notifications for Scheduled Pipeline Runs are correctly set up
Please create a GET API endpoint so that we can check whether users have been added to the Failure Notifications list for a scheduled pipeline. Instead of having to check this manually for each pipe...frithjof_v4 hours agoCommunity ChampionNew9Views0likes0Comments:: operator for typecast in T-SQL
Introduce support for the ::type cast operator in Fabric Data Warehouse as syntactic sugar for the existing CAST(... AS type) expression. The new operator would be functionally equivalent and compile...jovanpop-msft14 hours agoMicrosoft EmployeeNew43Views7likes1Comment