Networking Considerations for FME Flow Webhook Integrations

Introduction

Webhooks involve server-to-server or application-to-application communication. When Cloud systems are integrating with on-premises systems, there is often a firewall in the way. In this article, we'll look at Survey123's integration with FME Flow via webhooks as an example, and the considerations needed to safely open your network to allow the webhooks to reach their intended endpoints. 

Integrating Survey123 with FME Flow via webhooks is a powerful pattern for automating geospatial workflows — but getting it to work reliably requires a clear understanding of the network paths involved. A common source of confusion is where the webhook call actually originates — and the answer depends on which of the two Survey123 webhook types you are using. Feature layer webhooks are fired server-side by ArcGIS Online or Enterprise Portal — the mobile device plays no part. Survey123 app/form webhooks, however, are fired directly by the field app or browser at the moment of submission, meaning the device itself must have a network line of sight to the FME Flow endpoint.

This distinction is critical: your firewall and routing decisions must account for which webhook type is in use, as the network path — and therefore the requirements — differ significantly between the two.

This article applies to FME Flow 2023.x and later, ArcGIS Online, and ArcGIS Enterprise 10.9.1+. Networking capabilities may vary based on your organization's infrastructure and security policies.

How Survey123 Webhooks Work

Survey123 supports two webhook types with different network behaviors:

Feature layer webhooks — fired server-side. When a survey is submitted, the following sequence occurs:

1. The Survey123 mobile app (or web app) submits the survey response to the ArcGIS Online hosted feature layer or the ArcGIS Enterprise Portal feature layer.
2. The Survey123 backend (AGOL or Portal) detects the submission event.
3. The Survey123 backend sends an HTTP POST to the configured webhook URL—in this case, the FME Flow webhook endpoint.
4. FME Flow receives the payload and triggers the associated workspace or job.

The mobile device is out of the picture after step 1. It never contacts FME Flow directly.

Survey123 app/form webhooks — fired client-side. The flow is different:

1. The Survey123 field app or web form sends the survey response.
2. The app simultaneously fires an HTTP POST directly to the configured webhook URL — in this case, the FME Flow endpoint.
3. FME Flow receives the payload from the device, not from the ArcGIS backend.

For this webhook type, the mobile device must have direct network access to the FME Flow endpoint.

Architecture Diagrams by Deployment Scenario

Scenario 1: ArcGIS Online → FME Flow On-Premise

Key Networking Requirement: 

ArcGIS Online is a cloud service hosted by Esri. For it to POST to an on-premise FME Flow instance, the FME Flow webhook endpoint must be publicly accessible from the internet or reachable from Esri's known IP ranges.

The recommended approach is to place a reverse proxy (e.g., NGINX, IIS ARR, or an API gateway) in a DMZ or on a public-facing host that forwards traffic to the internal FME Flow server. FME Flow itself never needs to be directly exposed.

Esri publishes the IP ranges used by ArcGIS Online services, which can be used to restrict inbound access to only those addresses at the firewall level — reducing exposure significantly.

Mobile Device Requirements: 

No VPN needed. The mobile device only needs internet access to reach ArcGIS Online

Scenario 2: ArcGIS Enterprise (Portal) → FME Flow On-Premise

Key Networking Requirement:  

Because both Portal and FME Flow are on the same internal network, the webhook call is a straightforward internal HTTP/HTTPS request. No reverse proxy, no internet exposure, and no complex firewall rules are typically required — assuming standard internal routing between hosts.

Mobile Device Requirements: 

This is where VPN becomes relevant — but only for reaching Portal, not FME Flow. If the ArcGIS Enterprise Portal is accessible only on the internal network, field staff must be on VPN (or connected via Wi-Fi on the internal network) to submit their surveys. Once the submission reaches the Portal, the webhook to FME Flow is handled entirely within the network.

If Portal is exposed to the internet (via a reverse proxy or load balancer), mobile devices do not need a VPN. The FME Flow webhook still stays internal.

Scenario 3: ArcGIS Online or Enterprise → FME Flow Cloud-Hosted

Key Networking Requirement: 

This is the simplest networking topology. Both the Survey123 backend and FME Flow are accessible via the internet. No reverse proxy is required, no VPN is needed, and there are no inbound firewall rules to negotiate on-premise.

Mobile Device Requirements: 

Internet access only. No VPN.

VPN: When Is It Actually Required?

The key principle: for feature layer webhooks, a VPN is needed only to reach the Survey123 backend (Portal) — the mobile app never calls FME Flow directly. For Survey123 app/form webhooks, the device itself fires the call, so it must be able to reach the FME Flow endpoint regardless of which ArcGIS backend is in use.

Reverse Proxy Configuration

When ArcGIS Online needs to reach an on-premise FME Flow instance, a reverse proxy is the standard and recommended solution. The proxy exposes a single public-facing endpoint (e.g., https://fme.yourorg.com/fmeapiv4/) and forwards traffic internally to the FME Flow server.

Key considerations when setting up the reverse proxy:

• TLS/SSL termination: ArcGIS Online requires the webhook URL to use HTTPS with a valid, publicly trusted certificate. The reverse proxy should handle SSL termination using a certificate issued by a public CA (e.g., Let's Encrypt or DigiCert).
• URL path forwarding: Ensure the FME Flow webhook path is correctly proxied (e.g., /fmeapiv4/automations/...). Mismatched paths are a common configuration error.
• IP allowlisting: Restrict inbound connections to the proxy to Esri's published ArcGIS Online IP ranges. This prevents the public-facing endpoint from being called by arbitrary internet traffic.
• Internal firewall rules: Only the reverse proxy host should have inbound access to FME Flow on the relevant port (typically 443 or 80 internally). FME Flow itself should not be directly reachable from the DMZ or the internet.

Summary

The architecture decision largely comes down to one question: Is ArcGIS Online (Esri's cloud infrastructure) able to reach your FME Flow webhook endpoint? If yes, everything works. If not, a reverse proxy is the path forward — a well-understood, supported pattern that avoids exposing FME Flow directly to the internet.

There are many other such webhook integrations, such as CityWorks, that work in much the same way; thus, the above considerations can be readily applied in those situations as well.

Additional Resources

Enabling FME Flow for Public Access

If you are still experiencing issues, contact Safe Software Support.