Almost every ServiceNow engagement eventually needs to talk to something outside the platform — an HR system, a monitoring tool, a legacy on-prem application. The integration method you choose early on tends to stick around far longer than expected, so it's worth getting right.
Pattern 1: Direct REST API calls
The simplest option — scripted REST messages calling an external API directly. This works well for straightforward, low-volume, well-documented APIs where you need full control over the request/response handling.
Best for: simple, infrequent calls; situations where IntegrationHub's spoke ecosystem doesn't yet cover the target system.
Watch out for: logic scattered across Script Includes with no central visibility — this is one of the fastest ways to accumulate the technical debt we wrote about separately.
Pattern 2: IntegrationHub + Flow Designer
For most modern integrations, this is our default recommendation. It centralizes integration logic visually, comes with prebuilt Spokes for common systems (Slack, Microsoft Teams, Azure, AWS, and more), and is far easier for a future developer to understand at a glance than scattered scripts.
Best for: business-process-driven integrations — triggering an action in an external system as part of a workflow, not just fetching data.
Watch out for: IntegrationHub licensing is usage-based (based on number of actions/transactions), so high-volume integrations need cost modeling before committing to this pattern.
Pattern 3: MID Server
For anything behind a firewall — on-premise databases, internal APIs, legacy systems that were never meant to be internet-facing — a MID Server is the only viable path. It sits inside your network and relays communication back to your ServiceNow instance securely.
Best for: Discovery, on-prem system integration, anything that can't or shouldn't be exposed directly to the internet.
Watch out for: MID Server infrastructure needs its own maintenance plan — patching, monitoring, and redundancy if the integration is business-critical.
The real decision framework
The technical pattern matters less than asking upfront: is this data-fetching, or is this action-triggering? Is the target system internet-facing, or does it live behind a firewall? Those two questions eliminate two of the three patterns almost immediately.