Webhooks are a technology that has been inspired by the need for near-real-time connections between separate enterprise systems. While ETL processes, data exports and imports, or enterprise service buses have existed for many years, webhooks represent a new pattern for integrating between these systems and are increasingly implemented in a variety of types of software.
Webhooks can be most simply defined as a system-to-system message (a payload) that is sent after a certain action occurs (a trigger), whether the action or event occurs in a data management system or an application. These payload messages can vary in size, content, or scope, but in general, there is a pattern of a source system and a destination system, with webhooks configured in the source that send information to the destination. Rather than running on a time-based schedule, webhooks are usually triggered just-in-time, such as when a certain event occurs, including when a form is edited, a file is removed, a user is created, and so on.
A webhook usually consists at a technical level of a POST request to an HTTPS endpoint, which may be anonymously accessible or secured by a simple token or key. The contents of the POST relate to the event that has just occurred (see examples below) and the destination receives the message and processes it based on its own logic. These messages are most often JSON documents (by convention but not be definition) and can contain narrow or broad sets of information depending on how they were designed.
Webhooks are generally considered an effective, but not foolproof integration method. As they are loosely coupled to the destination endpoint, there is no guarantee that a message from the source system will reach the destination. Issues like network outages, a failed endpoint, or a badly constructed message body could cause that message to fail. This means that webhooks are not perfectly reliable, though not significantly different from any other REST API or endpoint which could suffer from the same reliability challenges.
Webhooks as a capability are usually added to a system or application for specific reasons, not as a base capability or process for all requests or interfaces. They are often used to get information, or event-based messages, into other systems that focus on notification or automation, such as Power Automate or Zapier. A webhook request could also be sent to a custom web service or endpoint or sent to an ArcGIS geoprocessing tool.
Additional recommendations related to webhooks, and sample code for receiving and processing webhooks, can be found in Esri’s webhook-samples Github repository.
Webhook capabilities are made available in several different parts of the ArcGIS system, and can be used to tie together workflows, integrate to other systems, and trigger related events that operate on the data contained in the webhook. Several ArcGIS applications or systems make native use of webhooks, including:
Webhooks in ArcGIS Online are made available in the context of feature services, which can be configured to send webhooks based on different conditions, such as a new feature or an edit, and to multiple destinations, for example, different endpoints might receive new features rather than edits. This blog post shares some examples of how webhooks can be created and used. The body of the webhook will contain information about the set of edited features, which the remote system can use to query back to ArcGIS Online and get the actual transactional changes.
Webhooks in ArcGIS Enterprise also support feature service-based webhooks, in a very similar way to ArcGIS Online, but also support several other patterns. These feature service-based webhooks are configured from the ArcGIS Server Administrator Directory. See create webhooks for details on how to configure a feature service-based webhook.
Geoprocessing service webhooks can be configured to run on completion of a geoprocessing service job, notifying a remote system that the job has completed, and include the results of the job (succeeded, failed, or cancelled) along with a URL that the remote system can use to fetch status. The contents of the geoprocessing service webhook are described in more detail in the ArcGIS Enterprise documentation.
In this blog post, an example of how to use feature service and geoprocessing service webhooks together is described, to automate a citizen reporting workflow with a work management system.
ArcGIS Enterprise also supports organization webhooks, which are triggered by changes to users, groups and content in the ArcGIS Enterprise deployment. These webhooks can be defined to run on a specific event type (such as the creation of a new group) or on many event types (allowing the remote system to parse and handle the events independently).
Both ArcGIS Survey123 and ArcGIS Field Maps support a webhook capability.
Field Maps provides a module for Make.com that eases integration of Field Maps workflows that use hosted feature services in ArcGIS Online. See Automate Field Maps for details.
In Survey123, similar workflows exist for both Make.com and ArcGIS Power Automate, but webhooks can also be manually configured so they are sent to a destination from the field application (when collecting data) or the Survey123 web form (when submitting data through a browser). See Configure a webhook in the Survey123 website for details.
To support integration with other systems and workflows, ArcGIS Workflow Manager provides an easy way to create an endpoint that receives webhooks, generally to create a job based on external information. See Create jobs with webhooks for details.
When designing a system or integration where webhooks will play an important role in a solution or workflow, it is important to consider some of the functional and non-functional requirements for webhooks to be successful. These considerations ensure that system users and stakeholders properly understand the role of webhooks in the system, and any limitations that exist.