Inquiry regarding MID Server usage for integrating with container-based APIs hosted on Azure

[NaoyaT]

Hi everyone,

I am currently planning an integration where ServiceNow calls an API running on a containerized application. I would like to clarify a few points regarding the implementation.

・Background / Network Environment
We are planning to test an integration where a ServiceNow instance calls an API hosted on a container application within a private environment on Microsoft Azure.
To facilitate this, we have deployed a MID Server on an Azure VM within the same (or a reachable) Virtual Network.

・Implementation Plan
We intend to use Flow Designer (IntegrationHub) with the following setup:
Method: Create a custom Action using a REST step.
Configuration: Check the "Use MID Server" option in the REST step and specify the MID Server hosted on Azure.

・Questions
1. Are there any potential oversights or technical concerns (such as Azure NSG settings or specific MID Server configurations) we should be aware of when proceeding with this plan?
2. Is my understanding correct that using a MID Server is mandatory when ServiceNow needs to call an API located inside a private Azure VNet?

I would appreciate any advice or insights you may have.
Thank you in advance!

[pr8172510 · Accepted solution]

Hi @NaoyaT,

 when an endpoint is not directly accessible from the ServiceNow instance (for example, an API hosted inside a private Azure VNet), a MID Server is required to route the REST call from ServiceNow to the private network.

Key considerations:

• MID Server status should be Up and Validated.
• The MID Server must be able to resolve the API hostname and reach the endpoint.
• Azure NSGs, firewalls, route tables, and private endpoints must allow traffic from the MID Server to the container application.
• If HTTPS is used, ensure the MID Server trusts the API certificate chain.

Your proposed architecture is the recommended pattern:
ServiceNow → Flow Designer REST Step → MID Server → Private Azure API

If the API is publicly accessible from the internet, a MID Server is not required. Otherwise, for private Azure resources, using a MID Server is the supported ServiceNow approach.

[pr8172510 · Accepted solution]

Hi @NaoyaT,

 when an endpoint is not directly accessible from the ServiceNow instance (for example, an API hosted inside a private Azure VNet), a MID Server is required to route the REST call from ServiceNow to the private network.

Key considerations:

• MID Server status should be Up and Validated.
• The MID Server must be able to resolve the API hostname and reach the endpoint.
• Azure NSGs, firewalls, route tables, and private endpoints must allow traffic from the MID Server to the container application.
• If HTTPS is used, ensure the MID Server trusts the API certificate chain.

Your proposed architecture is the recommended pattern:
ServiceNow → Flow Designer REST Step → MID Server → Private Azure API

If the API is publicly accessible from the internet, a MID Server is not required. Otherwise, for private Azure resources, using a MID Server is the supported ServiceNow approach.

[harishk07 · Accepted solution]

Hi @NaoyaT ,

A few additions worth knowing. On whether MID Server is mandatory: yes, for a privately hosted endpoint in an Azure VNet, MID Server is the supported pattern. The theoretical alternative of allowlisting ServiceNow's outbound IPs is weak in practice, because those IPs are shared across tenants in the datacenter and can change on failover. ServiceNow itself recommends MID Server or VPN when fixed source IPs are needed. So your design choice is sound.

A few things to plan for beyond what was already mentioned:

1. High availability. Deploy at least two MID Servers and put them in a Load Balancer cluster, then target the cluster from the REST step rather than pinning a single MID Server. 
2. DNS resolution inside the VNet. If your container API uses a private FQDN, the MID Server VM has to resolve it. 
3. Auth boundary. The MID Server is a network relay, not an auth proxy. Whatever the API expects (OAuth, basic, mTLS) still has to be configured on the ServiceNow Connection or REST Message. The MID Server just forwards the request.
4. Azure Container Apps specifics. The app sits behind the environment's edge envoy proxy. Confirm the Container Apps environment is set to internal, VNet integration is on, and your MID Server reaches the environment's internal FQDN, not the container directly.

If you can share which container service you are using (Container Apps, AKS, or ACI) and the auth method the API expects, happy to narrow down.

Best Regards,

Harish

[NaoyaT]

Hello, @pr8172510 , @harishk07 

Thank you for your detailed feedback.

I understand the requirements for the MID server and the logic behind them. Your suggestions regarding high availability and DNS resolution will be very helpful as we move forward with our planning.

We will now close this case.

Sincerely,
Naoya