Understand webhooks

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.

Webhooks in ArcGIS products

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:

  • ArcGIS Online hosted feature service webhooks
  • ArcGIS Enterprise organization, feature service, and geoprocessing service webhooks
  • Survey123 Field App and web form webhooks
  • ArcGIS Field Maps - Make.com integration with webhooks
  • Workflow Manager Server webhook receiver
  • ArcGIS Notebook Server

ArcGIS Online

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.

ArcGIS Enterprise

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).

ArcGIS mobile applications

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.

ArcGIS Workflow Manager

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.

Architecture considerations

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.

  • Webhooks require line of sight network connectivity. When an event occurs, webhooks are sent immediately, and if any network access or outage interrupts this request, it can mean that the payload never reaches the final destination. While some systems support automatic retry logic to re-send a webhook payload, this cannot always be relied on, and may result in lost messages in inconsistent network conditions.
  • Webhooks can contain sensitive information, and the destination should be carefully considered. Feature service and ArcGIS Enterprise organizational webhook payloads contain information about an operation and the user that made the operation, along with information that allows a request to be made by the receiver to obtain the details of that operation. Survey123 webhook payloads include the submitted feature along with other user and session-specific information. While most webhook workflows send payloads to a system that is also controlled and configured by the group that owns the GIS system, it is important to note that this information leaves ArcGIS in the webhook and should be treated carefully in the destination system.
  • Webhooks do not guarantee delivery. While retry intervals and attempts can try to achieve a higher rate of success, webhooks do not guarantee that every event or trigger will result in data reaching the destination system. While this can be acceptable for many workflows, consider whether a post-process to validate data completeness may be required to guarantee that all events were properly processed.