ServiceNow REST and SOAP Integrations: Guides and Services

REST and SOAP are two ways to connect ServiceNow with other applications. REST uses HTTP methods and suits most modern integrations. SOAP uses a structured XML messaging protocol and fits enterprise systems that need formal contracts. The choice depends on what the external system can support.

Understanding REST and SOAP in ServiceNow

REST and SOAP are two contrasting approaches to integrating ServiceNow with external applications. REST uses HTTP methods to retrieve or modify data, making it lightweight and suitable for most modern integrations. SOAP provides a more structured, XML-based messaging protocol often used in enterprise systems that require formal contracts and guaranteed delivery. In ServiceNow, you can expose data to other systems using REST APIs or SOAP web services, and you can also consume external REST and SOAP endpoints from within ServiceNow to pull or push data. Choosing between them depends on your external system’s capabilities and your integration complexity. Modern integrations typically prefer REST unless legacy constraints require SOAP.

How This Section is Organized

The guides in this section grouped by purpose help you understand common integration patterns and scenarios. We cover exposing ServiceNow data via REST and SOAP so external systems can read incident records, create requests, update configuration items, or retrieve other data. We explain how to consume external APIs—calling a weather service, retrieving currency exchange rates, synchronizing user accounts from an identity provider, or pulling data from business systems. We also cover real-time versus scheduled integrations: whether you need data to flow immediately when a record is created, or whether periodic batch synchronization is acceptable for your use case. The section includes guidance on middleware patterns when direct integration is not feasible, security considerations such as API authentication and encryption, error handling and retry logic, and troubleshooting approaches when integrations fail or behave unexpectedly.

Common Integration Scenarios

Many organisations integrate ServiceNow with their ERP system to automatically create incidents when procurement orders are delayed or when inventory drops below thresholds. Others integrate with financial systems to validate budget availability before approving requests, or with HR systems to automatically create access requests based on employee onboarding. A typical integration flow might be: a user creates a request in ServiceNow, a workflow calls an external API to verify they have budget authority, and depending on the response, the request is approved automatically or routed for manual approval. Integration patterns vary widely based on the systems involved and whether the external system has documented APIs or requires a third-party middleware connector.

REST API Basics in ServiceNow

ServiceNow’s REST API allows you to query tables, create records, update records, and delete records using standard HTTP verbs (GET, POST, PUT, DELETE, PATCH). You can filter results using query parameters, request specific fields only, and sort data in ascending or descending order. Authentication is typically done with OAuth tokens, service account credentials, or basic authentication with username and password. The API returns JSON by default, making it easy to parse responses in scripts, workflows, or external applications. Rate limiting is important to understand: your queries must not overwhelm the instance or consume excessive resources. Error responses include meaningful HTTP status codes and messages to help with debugging and understanding what went wrong.

SOAP Web Services in ServiceNow

ServiceNow also exposes tables via SOAP web services, particularly useful when integrating with older enterprise systems that prefer SOAP over REST. SOAP messages are XML-based and include metadata about what you are requesting and how the response should be structured. SOAP endpoints in ServiceNow require authentication and support operations such as query, create, update, and delete. The WSDL document describes the interface and operations available, allowing external systems to auto-generate client code. SOAP is less commonly used in new integrations but remains important for legacy system integration where the external system does not support REST.

Oblytech Support for REST and SOAP Integrations

Oblytech helps organisations design and implement integrations tailored to their architecture and requirements. We can architect integrations that scale to handle high volumes, handle error scenarios gracefully, and maintain data consistency across systems. We provide guidance on choosing between REST and SOAP based on your specific requirements, designing API strategies that future-proof your system, and selecting middleware when direct integration is not practical. We also help troubleshoot failed integrations, optimize performance, and establish monitoring so you know when integrations are working correctly. Our approach ensures that integrations are maintainable, documented, and monitored long after implementation.

Choosing REST or SOAP by what the other system can actually support

The choice between REST and SOAP is often settled by the system on the other end of the connection, not by ServiceNow. If the partner, supplier or internal application publishes a WSDL contract and expects WS-Security headers, SOAP is the path of least resistance, and fighting it adds cost without benefit. If the other side offers a JSON API with token authentication, REST is normally simpler to build, test and debug. The mistake to avoid is choosing on personal preference and discovering late that the client library, certificate handling or message format does not match the endpoint.

A second factor is who maintains the integration after go-live. REST calls are easy to inspect with common tools and easy for a second developer to pick up. SOAP messages are verbose and depend on a contract file that must be kept in step with the provider. Neither is wrong, but the team that will own the integration for years should be the one choosing, and it should say so in the design record.

A decision table for the common integration situations

An ordered checklist before a new endpoint goes live

1. Obtain the provider’s contract and confirm which version the integration will target, along with the date it is expected to change.
2. Decide the authentication method and who holds the credential. Store secrets in a credential alias rather than inside a script.
3. Define the timeout, the retry count and the back-off, and decide which failures are safe to retry. A create call that retries without an idempotency key can create duplicate records.
4. Agree the error contract: which status codes or fault codes mean a retry, which mean a fix, and which should raise a ticket for the owner.
5. Test with a deliberately invalid payload, an expired credential and a slow response, not only with a successful call.
6. Name the owner, the monitoring signal and the person who will rotate the credential before it expires.

What operating the integration looks like after launch

Many integration failures appear after launch, when a credential expires quietly, a supplier updates a field type, or a volume increase pushes calls into the timeout. The operating model should therefore be designed before go-live. Keep a register of every endpoint with its owner, its contract version and its credential expiry. Review failed calls on a set rhythm rather than waiting for a complaint. When a provider announces a change, plan it as a project with a test window of its own, not a patch applied on the day.

Versioning deserves particular care. A change to a payload field can break a consumer that never asked for it. Where possible, add fields rather than altering or removing them, and where a breaking change is unavoidable, run the old and new versions side by side until every consumer has moved.

Follow-up questions on REST and SOAP work

Can we use both protocols for the same integration?

You can, when the provider offers both and each side has a reason. Running two protocols for one data flow doubles the monitoring and the failure modes, so the default should be one, with the second added only for a clear need.

Why does a call work in testing but fail in production?

Common causes are a different credential or role, a network path that has not been opened, a certificate that does not match the production endpoint, or a payload that only occurs with real data. Compare the production configuration against the test one before changing the code.

Is it worth wrapping every call in a generic framework?

A shared pattern for retries, logging and error handling is worth having. A framework that hides the contract and the failure behaviour from the people who maintain it often becomes the thing nobody can debug.

Who should approve a new external endpoint?

The owner of the data being exchanged, together with the security owner for the authentication design. Approval by the developer alone tends to miss what the data means to the business.

The outbound REST message explained guide describes the parts involved in calls the platform makes, and the REST integration design article goes further on design decisions. For inbound endpoints, the scripted REST API design contracts and the API contract versioning articles are the closest companions. The best practices guide sets out the habits that hold up over time.