Outbound Web Services — Endpoint Errors (4xx/5xx)<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Contents 1. Issue2. Status Code Quick Reference3. Root Causes 3.1 HTTP 400 Bad Request — malformed or invalid request body3.2 HTTP 404 Not Found — wrong endpoint URL3.3 HTTP 429 Too Many Requests — endpoint rate limiting the caller3.4 HTTP 500 Internal Server Error — endpoint-side exception3.5 HTTP 502 Bad Gateway — proxy or load balancer failure3.6 HTTP 503 Service Unavailable — endpoint temporarily down3.7 SOAP Fault responses3.8 Works in Postman, fails from ServiceNow 4. Diagnostic Steps5. MID Server — Additional Considerations6. Resolution Summary7. Related Articles 1. Issue An outbound REST or SOAP call from ServiceNow reaches the endpoint successfully — the connection and TLS handshake completed — but the endpoint returns an error status code in the 4xx or 5xx range. The call failed on the endpoint side or at a gateway between ServiceNow and the endpoint. Symptoms this article covers: Response status in sys_outbound_http_log is 400, 404, 429, 500, 502, or 503.The call works from Postman but fails from ServiceNow.The call succeeds in one environment (e.g. Dev) but fails in another (e.g. Prod).Intermittent 502 or 503 errors correlated with maintenance windows at the endpoint.SOAP calls return a SOAP Fault body with a faultstring element.The response body contains a JSON or XML error message from the endpoint describing the problem. Scope of this article This article covers errors returned by the remote endpoint or by a gateway in front of it — not ServiceNow-side failures. If the response status in sys_outbound_http_log is HTTP 0 or -1, the connection never completed: see KB3067060 — Connection Failures & TLS Errors. If the status is 401 or 403, see KB3067106 — Authentication & Authorization Failures. If the status is 504, see KB3067152 — Timeouts & Slow Responses. 2. Status Code Quick Reference Diagnostic decision path For any endpoint error, the Postman test in Step 3 below is the most important diagnostic action. It determines in one step whether the issue is in the request ServiceNow is sending, or in the endpoint itself. 3. Root Causes 3.1 HTTP 400 Bad Request — malformed or invalid request body A 400 means the endpoint received the request but rejected it because the request itself is invalid. The endpoint processed it far enough to determine the request is malformed — the credentials and connection were fine. Common causes in outbound calls from ServiceNow: Missing required fields. The endpoint expects a field in the JSON or XML body that ServiceNow is not sending. This often surfaces after an endpoint API version upgrade at the third party.Wrong Content-Type header. The endpoint expects application/json but ServiceNow is sending application/xml or no content type at all. Set the correct header on the REST message method record under the HTTP Request tab.Encoding issues. Special characters in field values not properly escaped in the JSON body. Inspect the Request tab body in sys_outbound_http_log for unescaped quotes, null bytes, or encoding artefacts.API version mismatch. The endpoint URL or request format changed in a new version of the third-party API but the ServiceNow REST message record was not updated.Body sent when endpoint expects no body (or vice versa). Some endpoints return 400 for GET requests that include a body. Resolution: Open the failing sys_outbound_http_log record and read the Response tab. The endpoint's 400 response body almost always describes the specific problem (e.g. "error": "field 'priority' is required").Open the Request tab and compare the request body and headers against the endpoint's API documentation.Test the corrected request in Postman to confirm the fix before updating the REST message record in ServiceNow.Update the REST message method record: fix the request body template, add or correct the Content-Type header, or adjust the HTTP method if required. 3.2 HTTP 404 Not Found — wrong endpoint URL The endpoint URL in the REST or SOAP message record points to a path that does not exist at the endpoint. This is commonly a configuration error rather than a code issue. Common causes: The endpoint was migrated to a new base URL or a new path structure and the REST message record was not updated.A typo in the endpoint URL or HTTP method path on the REST message record.The resource being requested (e.g. a specific record ID) does not exist at the endpoint.Environment-specific URLs (Dev endpoint vs. Prod endpoint) are mismatched. Resolution: Confirm the endpoint URL is correct by testing it from Postman. A 404 from Postman confirms the URL itself is wrong.Update the REST message record endpoint URL or method path to the correct value.If the URL includes a dynamic resource identifier (e.g. a record ID from a variable), confirm the variable is being populated correctly before the call is made. 3.3 HTTP 429 Too Many Requests — endpoint rate limiting the caller The endpoint is intentionally throttling the rate of requests from ServiceNow. Unlike inbound rate limiting (where ServiceNow enforces limits on callers), this is the remote endpoint applying its own limits to ServiceNow as a client. Common causes: A high-volume integration (bulk record sync, scheduled export) is sending requests faster than the endpoint allows.Multiple flows or scripts are calling the same endpoint concurrently, and the combined rate exceeds the endpoint's per-client limit.The endpoint has a per-day or per-hour quota that has been exhausted. The endpoint will typically include a Retry-After header on the 429 response indicating how long to wait before retrying. Check the Response tab in sys_outbound_http_log for this header. Resolution: Implement client-side retry logic that honours the Retry-After header. If absent, use exponential backoff with jitter.Reduce the call frequency from ServiceNow — add delays between requests, batch writes where the endpoint supports bulk operations, or spread calls across a longer time window.If the rate limit is a hard business constraint, engage the endpoint team to request a higher quota for the ServiceNow integration service account. 3.4 HTTP 500 Internal Server Error — endpoint-side exception A 500 means something went wrong inside the endpoint when processing the request. The request was received and passed basic validation, but the endpoint threw an unhandled exception during processing. Responsibility for the fix lies with the endpoint team. Common patterns from case data: The endpoint has a bug triggered by a specific combination of field values in the request body.The endpoint's database or downstream dependency is unavailable.The endpoint is healthy but a specific record or resource state causes a processing exception.Intermittent 500s that self-resolve point to transient endpoint-side load or resource exhaustion. The diagnostic priority is confirming that the 500 is genuinely endpoint-side and not caused by something in the ServiceNow request. Resolution: Test the identical request from Postman. If Postman also returns 500, the endpoint team owns the investigation — share the exact request body and headers.If Postman succeeds with the same body and credentials, compare the requests exactly: check for encoding differences, extra headers ServiceNow adds by default, or differences in how variable values are substituted in the body template.Check whether the 500 is intermittent or consistent. Consistent 500s on all calls point to a request content issue. Intermittent 500s suggest endpoint instability.For intermittent 500s, implement retry with backoff — the endpoint will typically recover on retry. 3.5 HTTP 502 Bad Gateway — proxy or load balancer failure A 502 is generated by a gateway or reverse proxy sitting in front of the endpoint. The gateway received the request from ServiceNow but could not get a valid response from the upstream endpoint server. A 502 confirms: the network path from ServiceNow to the gateway is working. The problem is between the gateway and the endpoint, or the endpoint is completely down. Common causes: The endpoint application server is down or crashed, but the load balancer is still accepting connections.The endpoint is being redeployed and is temporarily unavailable.The gateway's upstream connection pool is exhausted.For MID Server calls: a proxy on the MID Server's network path returned the 502. Resolution: Check the Response tab headers for a Via or Server header identifying the gateway. This confirms it is gateway-issued.Confirm whether the endpoint is accessible at all — test from Postman. A 502 from Postman too confirms the endpoint is down at the gateway level.Engage the endpoint team. This is an infrastructure issue on their side.Implement retry with backoff. 502s during a deployment window typically resolve within minutes. 3.6 HTTP 503 Service Unavailable — endpoint temporarily down A 503 is returned by the endpoint (or a gateway) when the service is temporarily unavailable. Unlike a 502 (which signals a gateway-to-endpoint communication failure), a 503 is explicitly issued by the endpoint or gateway to signal intentional temporary unavailability. Common causes: The endpoint is in a scheduled maintenance window.The endpoint is overloaded and shedding load.A deployment is in progress and the endpoint is temporarily unresponsive. Resolution: Check whether the 503 is time-correlated with a known maintenance window at the endpoint.Implement retry with exponential backoff. 503s are typically transient.Check for a Retry-After header in the response — the endpoint may indicate when it expects to be available again.If 503s are sustained for more than 15–20 minutes, escalate to the endpoint team. 3.7 SOAP Fault responses SOAP integrations use a different error signalling mechanism. When a SOAP call fails at the endpoint, the endpoint returns HTTP 200 with a SOAP Fault XML body rather than a 4xx or 5xx status code. The sys_outbound_http_log Response Status may show 200, but the Response body will contain a <faultstring> element describing the actual error. A SOAP Fault body structure looks like: <soap:Fault> <faultcode>soap:Client</faultcode> <faultstring>Invalid value for field 'priority'</faultstring> </soap:Fault> Common faultcode values and what they mean: Fault code Meaning Fix direction soap:Client The request was malformed or invalid. The client (ServiceNow) sent something the endpoint cannot process. Fix the SOAP message body or headers in the ServiceNow SOAP message record. soap:Server The endpoint encountered a server-side error while processing a valid request. Endpoint team investigation. Share the full fault body. soap:VersionMismatch The SOAP envelope version in the ServiceNow request does not match what the endpoint expects. Check the SOAP namespace and version in the SOAP message record. Resolution: Open the sys_outbound_http_log record, open the Response tab, and read the full XML body for the <faultstring> content.Match the faultcode to the table above to determine fix ownership.For soap:Client faults, compare the SOAP envelope being sent (Request tab) against the endpoint's WSDL to identify the mismatch.Enable verbose logging on the SOAP message record (Set HTTP Log Level → All) if the Response tab does not contain the full fault body. 3.8 Works in Postman, fails from ServiceNow When the identical request succeeds in Postman but fails from ServiceNow, the endpoint is working correctly. Something differs between what ServiceNow sends and what Postman sends. This is one of the most common patterns across outbound 4xx/5xx cases. The most common differences to investigate: Difference Where to check Fix Content-Type header mismatch Request tab in sys_outbound_http_log Add or correct the Content-Type header on the REST message method HTTP Request tab Extra headers ServiceNow sends by default Request tab — compare all headers against Postman Identify which extra header the endpoint rejects; suppress if possible via REST message configuration Variable substitution producing unexpected values Request tab body — check actual values substituted for script variables Add null/empty checks and escaping to the script populating the request body IP allowlist at endpoint If Postman works from your machine but ServiceNow gets 403 Allowlist ServiceNow instance IP range or MID Server IP at the endpoint. See KB3067106. Body encoding difference Request tab body — look for escaped characters, encoding artefacts Ensure the body is constructed as a proper JSON or XML string without double-encoding Environment-specific endpoint configuration Compare the REST message records across Dev, Test, Prod Confirm endpoint URL, credentials, and headers are environment-appropriate 4. Diagnostic Steps Confirm the status code and scope. Check the Response Status in sys_outbound_http_log. If 0 or -1 → KB3067060. If 401/403 → KB3067106. If 504 → KB3067152. Otherwise, continue.Read the Response tab body. The endpoint's error message is almost always the fastest path to root cause. Copy the exact error string before doing anything else.Enable verbose logging if the body is empty. Navigate to the REST or SOAP message record → select method → Related Links → Set HTTP Log Level → All. Re-run the failing call. Re-check the Response tab for the full body.Reproduce in Postman. Run the identical request using the same credentials and endpoint. This is the critical diagnostic split: Postman also fails → endpoint-side issue. Share the error body with the endpoint team.Postman succeeds → ServiceNow request differs from Postman. Go to step 5. Compare the requests. Use the Request tab in sys_outbound_http_log and compare every header and the full request body against what Postman sends. See Section 3.8 for the common differences.For MID Server calls: confirm which system is generating the error. Check the ECC Queue Input probe payload for the full response. Check MID Server agent log for any additional error context.Before opening a case, capture: Full response body and status code from sys_outbound_http_log Response tab.Full request headers and body from the Request tab.Whether Postman also returns the same error with identical credentials and body.Whether the failure is consistent or intermittent.Whether the failure occurs in all environments or only specific ones.MID Server name if the call routes via MID Server. 5. MID Server — Additional Considerations When outbound calls route through a MID Server, 4xx and 5xx errors behave the same as on direct calls — the endpoint returns an HTTP error code, and the MID Server passes it back through the ECC Queue. However, two MID Server-specific considerations apply: The error body may be in the ECC Queue Input payload, not the Outbound HTTP log. If the sys_outbound_http_log record shows a status code but an empty Response body, check the ECC Queue Input probe record for the full response payload. The MID Server includes the full response in the ECC payload, which the instance then surfaces in the log — but large payloads may be truncated or stored as an attachment on the ECC record.The MID Server's IP is what the endpoint sees. For IP-allowlist-related 403s, it is the MID Server host's egress IP that needs to be allowlisted at the endpoint, not the ServiceNow instance IP range. See KB3067106 for IP allowlist resolution steps. Large response payloads via MID Server If the endpoint returns a large error body (e.g. a verbose HTML error page from a gateway), the MID Server may exceed the ECC Queue payload size limit (mid.eccq.max_payload_size). In this case the payload is written to <MID_HOME>/agent/work/monitors/ECCSender/output_oversize and never sent to the instance. The sys_outbound_http_log record will show a status code with an empty body. To retrieve the full response, check this folder on the MID Server host directly. 6. Resolution Summary Status code Root cause Fix ownership Fix action 400 Malformed body, wrong Content-Type, missing required field ServiceNow configuration Fix request body or headers in REST/SOAP message record 404 Wrong endpoint URL or path ServiceNow configuration Update endpoint URL in REST/SOAP message record 429 Endpoint rate limiting ServiceNow as a client Integration design Implement backoff; reduce call frequency; batch writes; request quota increase from endpoint team 500 Endpoint-side exception Endpoint team Share exact request body; endpoint team investigates; retry for intermittent cases 502 Gateway cannot reach upstream endpoint Endpoint / network team Retry with backoff; endpoint team investigates infrastructure 503 Endpoint temporarily unavailable Endpoint team Retry with backoff; check Retry-After header; escalate if sustained SOAP Fault soap:Client SOAP request malformed or invalid ServiceNow configuration Compare SOAP envelope against WSDL; fix SOAP message record SOAP Fault soap:Server Endpoint-side exception on a valid SOAP request Endpoint team Share full fault body with endpoint team Any code — works in Postman, fails from ServiceNow Request difference between ServiceNow and Postman ServiceNow configuration Compare headers and body; fix Content-Type, encoding, variable substitution, or IP allowlist 7. Related Articles KB0659194 - Outbound Web Services — Troubleshooting GuideKB3067060 — Outbound Web Services — Connection Failures & TLS ErrorsKB3067106 — Outbound Web Services — Authentication & Authorization FailuresKB3067152 — Outbound Web Services — Timeouts & Slow ResponsesKB0659194 — Troubleshooting outbound REST web servicesKB0694711 — RESTMessageV2 and SOAPMessageV2 execute() vs executeAsync() best practicesKB0855595 — How the ECC Queue table records get processedKB0960404 — MID Server Landing PageKB0998511 — Capturing localhost logs for Outbound Web Service issues