ServiceNow IntegrationHub: REST Message v2 socket timeout when querying regchecker API

[regchecker]

Hello ServiceNow Developer Community,

We are currently configuring an enterprise Asset Management workflow inside ServiceNow Cloud to manage our client company vehicle fleet.

When an ITSM agent logs an asset ticket for a corporate vehicle, an automated IntegrationHub Action executes an outbound REST Message v2 GET call to an external UK vehicle verification service (regchecker.co.uk) to populate asset fields like MOT expiry date, engine size, and fuel type.

System Architecture and Workflow Setup:

• Data Endpoint: (regchecker.co.uk)

• Mechanism: ServiceNow Flow Designer -> IntegrationHub Custom Action -> REST Message v2 HTTP GET -> Map JSON response to alm_hardware custom fields.

• Environment: ServiceNow Washington DC / Utah Release.

Technical Issue and Query:

1. REST Message v2 Execution Timeout: Intermittently, the ServiceNow MID Server or Direct Cloud call drops connection with error SocketTimeoutException: Read timed out after 5000ms, whereas the same endpoint responds under 200ms in Postman outside ServiceNow infrastructure.

2. JSON Parser Array Script Error: When the returned JSON payload contains empty MOT advisory arrays from regchecker.co.uk, the ServiceNow target script parser throws a NullPointer Error during dynamic mapping.

Troubleshooting Steps Taken:

• Added explicit Accept: application/json headers in the ServiceNow REST Message configuration.

• Confirmed backend query speeds directly on regchecker.co.uk complete rapidly on independent network tests.

Has anyone experienced intermittent MID Server REST socket timeouts or JSON parsing issues when calling external APIs inside ServiceNow IntegrationHub Actions? Any recommended MID Server configuration parameters for handling external HTTP GET REST calls?

Thanks in advance!

[kmohammed]

Hi, both symptoms have fairly specific causes - take them separately.

1. The 5000ms socket timeout

A read timeout at exactly 5000ms, against an endpoint that answers in ~200ms from Postman, almost never means the endpoint is slow. It means the response is not arriving on the path ServiceNow actually uses, and something on that path gives up at 5 seconds. Postman tests your network path, not the instance/MID egress path, so it rules out the API but not the route. Work through it in this order:

- Fix the path first: decide whether the call should go Direct or via a specific MID Server and pin it (REST Message > "Use MID Server"). Intermittency often appears when the call sometimes goes direct (through the instance egress/proxy) and sometimes through a MID with different firewall/DNS behaviour. Then reproduce from that exact hop: from the MID host, resolve and curl the regchecker endpoint repeatedly - a classic pattern here is DNS returning multiple addresses where one is dead, so roughly every nth request hangs until the socket timeout while the others return instantly.

- Raise the timeout on the call itself while you diagnose, so a slow-but-working response can complete: set an explicit HTTP timeout on the REST Message v2 request (setHttpTimeout on the RESTMessageV2 call, or the Timeout value on the REST step of the IntegrationHub action) instead of relying on the effective default, and log the actual elapsed time per attempt.

- Turn on Outbound HTTP logging and inspect sys_outbound_http_log for the failing executions: compare MID used, target IP, status and duration between the passes and the timeouts. The timeouts will cluster on one hop/IP, which tells you whether it is DNS, the MID host's egress firewall, or an upstream proxy resetting idle/kept-alive connections (also worth testing: disable connection reuse problems by sending a "Connection: close" header on this endpoint - some CDNs/WAFs drop reused connections and the client then waits for a response that never comes).

- Because this is an idempotent GET behind a lookup, add an IntegrationHub retry policy (retry on timeout/connection errors with a short backoff, 2-3 attempts). That is a legitimate fix for the residual intermittency once the bad hop is identified, not a substitute for finding it.

2. The JSON parser NullPointer on empty arrays

This one is expected behaviour of the parser/mapping layer, not bad data. When the MOT advisory array is present but empty (or absent), any parser step or dynamic mapping that addresses an element - e.g. mapping something like advisories[0].text or iterating the array to build target fields - evaluates to null and the dynamic mapping dereferences it, producing the NullPointer error.

Fix: stop mapping array elements directly in the parser step. Parse the response in a Script step (or a pre-processing step of the action) and normalize it first: parse JSON, then explicitly test the array before touching it - if the advisory node is null or its length is 0, set a safe default (empty string / empty array output) and only read element 0 when length is greater than 0. Feed the downstream parser/mapping step only the normalized structure. Guard the same way for any other optional arrays in that API, because present-but-empty and missing are both normal responses for a vehicle with no advisories - the ticket flow should record "no advisories returned" and continue, not fail the action.

Regards,

Karimuddin