-Should an Enterprise Orchestration Engine Raise Webhooks?

This blog post presents some perspectives regarding whether an Enterprise Orchestration Engine should raise webhooks when events occur in the system. I would be very grateful for any comments on this topic, especially describing any relevant use cases.

Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:

• jpw3.com

Quickly, a webhook is basically an outbound HTTP request that a customer configures a system to generate when an event occurs. Webhooks are signals from one application to another. Webhooks have some challenges, such as that they are often “fire and forget”, there is no guarantee that they will arrive in order, and they demonstrate the lack of large-scale transactions in composable architecture.

This post is about webhooks outbound from Orchex. Inbound webhooks can invoke orchestration processes, whether by using the Orchex default endpoint for invoking orchestration processes or by implementing a custom route in the EOE that invokes an orchestration process that handles the webhook payload.

The classic example is content management publishing, which can raise webhooks to clear caches and update search indexes. If a system publishes a large number of entries, the webhook either intercepts and operates on each publish event or operate only on the publish complete event. In either case, there are data synchronization risks between the CMS, the publishing target, the search index, and various caches.

Currently, there aren’t very many events that could raise webhooks in Orchex. Some data changes in a store, such as processor definitions (note: this always happens through APIs, which can be orchestrated). A scheduled process runs. An orchestration processor runs. All these things could generate webhooks. But do they need to? For one thing, I haven’t come across a use case that would involve EOE webhooks. For another, one can implement equivalent functionality with orchestration processors.

If Orchex implements webhooks, it will almost certainly implement them with orchestration processes, which leads to consistent architecture and flexibility. But we’re thinking that we might not need to.

An orchestration process can simply include a processor that performs functionality equivalent to what a webhook would do, but without the limitations of webhooks or the need to understand how the EOE vendor’s webhooks work. To mimic a webhook, such a processor could fire HTTP request without waiting for its response, but maybe the response could be of value, and with processors, you have the option to wait and process any response from the webhook listener. That covers both scheduled processes and orchestration process invocation API calls, but not other API calls, such as the EOE webservice API to define a processor.

That brings up an interesting topic. We’re thinking about not exposing the EOE API to the public. Instead, we would implement orchestration processors that call the EOE APIs, so implementations could use orchestration processes to interact with Orchex just like they use Orchex to interact with external systems. These orchestration processes would be configurable, so customers could add orchestration processors that perform functionality equivalent to webhooks around the Orchex webservice API calls.

To summarize, we’re thinking about just using orchestration process infrastructure instead of coming up with some proprietary webhook solution. Once you start using orchestration processes for any webservice API, you basically want to use an EOE for anything that calls an endpoint that involves JSON.