.png)
ServiceNow Integration Guide
Integrate ServiceNow with enterprise applications through REST and SOAP APIs, configured outbound callbacks, Import Sets, attachment endpoints, and orchestrated workflows.
ServiceNow integration options at a glance
ServiceNow’s primary integration surface is its REST API, including the Table API, Import Set API, Attachment API, scripted REST resources, and product-specific endpoints. SOAP web services remain available for WSDL-based and legacy integrations. Configured outbound REST messages, business rules, flows, and event mechanisms can call external Martini APIs, although event coverage depends on the selected ServiceNow feature rather than a universal webhook stream. Import Sets, pagination, filtered queries, exports, and selected asynchronous operations support larger exchanges. Martini can authenticate with configured ServiceNow credentials, orchestrate workflows, map and transform payloads, process attachments, and apply checkpoints, validation, retries, and idempotency controls.
| Integration point | Supported by ServiceNow? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | ServiceNow’s Table API, Import Set API, Attachment API, scripted REST resources, and product-specific APIs support querying, creating, updating, and retrieving Incidents, Users, Configuration Items, Change Requests, and other tables. | Martini can consume ServiceNow REST endpoints from workflows, map request and response payloads, expose REST APIs for ServiceNow callbacks, and apply validation, business rules, retries, and checkpointing. |
| SOAP APIs | Yes | SOAP web services and scripted SOAP services support WSDL-based interfaces and legacy enterprise integrations where REST is not available or cannot be adopted. | Martini can consume ServiceNow SOAP services and transform XML responses into canonical models or downstream formats. |
| Webhooks / outbound callbacks | Limited | Outbound REST messages, business rules, Flow Designer actions, scripted requests, and event mechanisms can call external endpoints for configured events and processes. | Martini can expose a REST API endpoint for ServiceNow callbacks, validate and normalize notifications, route them through workflows, and return controlled responses. Coverage is configured and event-specific. |
| Bulk / async / batch APIs | Yes | Import Set APIs, pagination, filtered queries, aggregate queries, exports, and selected asynchronous operations support larger data exchanges and staged loading. | Martini can process pages or batches, transform staged data, persist high-water marks, and control concurrency and retry behavior. |
| File / attachment APIs | Yes | Attachment operations support uploading, downloading, querying, and deleting files associated with ServiceNow records such as Incidents and Change Requests. | Martini can retrieve attachment metadata and binary content, transform or route files, and deliver them to another API, file system, database, or application. |
| Authentication | Yes | ServiceNow supports Basic Authentication, OAuth 2.0, API keys for selected scenarios, mutual TLS, roles, ACLs, OAuth scopes, and web-service access controls depending on instance configuration. | Martini can use environment-managed secrets and configured authentication when consuming ServiceNow APIs or exposing Martini APIs for ServiceNow callbacks. |
| Database / analytics access | Limited | ServiceNow provides reporting, aggregate queries, exports, and analytics, but direct access to the underlying SaaS database is not the normal integration approach. | Martini should consume supported ServiceNow APIs, exports, Import Sets, or reporting interfaces rather than relying on direct SQL access to the ServiceNow database. |
How ServiceNow exposes data and business events
ServiceNow REST APIs
ServiceNow REST APIs are the primary integration surface for new application integrations. The Table API supports CRUD-style access to platform tables, while Import Set, Attachment, scripted REST, aggregate, and product-specific APIs support specialized workloads.
Martini implementation pattern
Martini implementation pattern: Martini workflows authenticate to the target ServiceNow instance, send filtered and paginated REST requests, normalize JSON responses, resolve reference fields, apply business rules, and write results to downstream systems or expose a controlled API for inbound requests.
Implementation sequence
ServiceNow SOAP APIs
ServiceNow supports SOAP web services, including platform and scripted SOAP services. SOAP remains relevant for WSDL-based enterprise interfaces and legacy integrations, although REST is generally preferred for new work.
Martini implementation pattern
Martini implementation pattern: Martini consumes the WSDL-based SOAP service, handles XML request and response structures, transforms the result into a canonical model, and routes SOAP faults or downstream failures through workflow error handling.
Implementation sequence
ServiceNow outbound callbacks
ServiceNow can initiate outbound requests through Outbound REST messages, business rules, Flow Designer actions, scripted requests, and event mechanisms. These callbacks are configured for selected processes and events rather than exposed as a universal webhook stream.
Martini implementation pattern
Martini implementation pattern: Martini exposes a REST API endpoint, receives the configured ServiceNow request, validates its authentication and payload, deduplicates the notification, and invokes a workflow that creates, updates, or routes the relevant business object.
Implementation sequence
ServiceNow bulk and Import Set processing
Import Set APIs, staging tables, transformation maps, pagination, filtered queries, exports, and selected asynchronous operations support larger exchanges. Exact behavior varies by API and ServiceNow product area.
Martini implementation pattern
Martini implementation pattern: Martini retrieves or receives data in controlled pages or batches, transforms it to the Import Set or target schema, tracks checkpoints, and separates validation failures from transient request failures.
Implementation sequence
ServiceNow attachment APIs
ServiceNow attachment endpoints support uploading, downloading, querying, and deleting files associated with platform records. Requests may use multipart content or binary data depending on the endpoint.
Martini implementation pattern
Martini implementation pattern: Martini retrieves the parent record and attachment metadata, handles binary content separately from record fields, and routes the file to a downstream API, file system, database, or application while retaining correlation information.
Implementation sequence
Common ServiceNow integration patterns
Pattern 1: Synchronize Incidents with a support platform
When to use this pattern
Use this pattern when customer-impacting ServiceNow Incidents must be visible in another support or CRM platform. A scheduled workflow can retrieve new or updated Incidents, enrich caller and service context, and synchronize status in one or both directions without creating duplicate cases.
Integration direction
Example Mapping
| ServiceNow Field | Canonical Field | Target Field |
|---|---|---|
| sys_id | sourceIncidentId | externalIncidentId |
| number | incidentNumber | caseNumber |
| short_description | summary | subject |
| priority | priority | casePriority |
Martini implementation pattern
Martini queries Incidents using sys_updated_on and pagination, resolves reference fields such as caller and service, maps the payload to a canonical support model, and applies rules for severity, ownership, and update direction. It searches for the external correlation key before creating a case, persists the checkpoint after successful processing, and retries transient failures without duplicating records.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- checkpointing
- error handling
Pattern 2: Coordinate Change Requests with deployment workflows
When to use this pattern
Use this pattern when an approved ServiceNow Change Request must initiate deployment or project work and receive implementation results. It supports validation of risk, approval, scheduling, and ownership before an external operation starts.
Integration direction
Example Mapping
| ServiceNow Field | Canonical Field | Target Field |
|---|---|---|
| number | changeNumber | issueKey |
| short_description | changeSummary | summary |
| risk | changeRisk | priority |
| start_date | plannedStart | plannedStart |
Martini implementation pattern
Martini retrieves or receives an eligible Change Request, validates approval and required scheduling fields, maps it to the target work item, and calls the downstream API. The workflow records the target identifier, applies controlled status transitions, and writes deployment or implementation results back to ServiceNow while routing rejected or failed operations for review.
Martini capabilities used
- workflows
- API orchestration
- data mapping
- validation
- business rules
- error handling
Pattern 3: Create Incidents from monitoring alerts
When to use this pattern
Use this pattern when an observability application should create or update ServiceNow Incidents from operational alerts. It is suitable for event-driven ingestion where deduplication, severity routing, and acknowledgment behavior are important.
Integration direction
Example Mapping
| ServiceNow Field | Canonical Field | Target Field |
|---|---|---|
| alert_id | sourceAlertId | correlation_id |
| title | summary | short_description |
| priority | severity | priority |
| message | details | description |
Martini implementation pattern
A Martini API receives the supported monitoring notification, validates the payload, normalizes severity and service identifiers, and checks for an existing Incident using the alert correlation key. The workflow creates or updates the Incident through the Table API, applies suppression and assignment rules, and returns an acknowledgment while logging failures for retry.
Martini capabilities used
- APIs
- webhooks and callbacks
- data mapping
- deduplication
- business rules
- error handling
Pattern 4: Synchronize CMDB Configuration Items
When to use this pattern
Use this pattern when ServiceNow Configuration Items must be distributed to an inventory, analytics, or monitoring application. Incremental filters and checkpoints reduce load on the ServiceNow instance and avoid repeatedly scanning large tables.
Integration direction
Example Mapping
| ServiceNow Field | Canonical Field | Target Field |
|---|---|---|
| sys_id | configurationItemId | externalId |
| name | itemName | name |
| sys_class_name | itemClass | resourceType |
| operational_status | operationalStatus | status |
Martini implementation pattern
Martini queries changed Configuration Items with a time-window filter and stable sys_id ordering, maps class and ownership fields, and applies rules for supported target resource types. It upserts target objects using the ServiceNow identifier, persists a high-water mark only after successful delivery, and routes schema, ACL, and rate-limit failures according to their recoverability.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination
- data transformation
- idempotency
- checkpointing
Applications commonly integrated with ServiceNow
ServiceNow is commonly connected with customer, identity, development, workforce, collaboration, observability, and enterprise resource applications. Martini can coordinate these flows using ServiceNow APIs, configured callbacks, reusable workflows, and canonical data mappings.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer-impacting support issues, account context, service requests, and ServiceNow Incidents or Users across customer and service operations. | ServiceNow → Martini → Salesforce | Martini retrieves changed Incidents and related context, resolves reference fields, maps them to Salesforce cases or account-related data, and optionally propagates approved status changes back to ServiceNow with correlation-key checks and retry handling. |
| Microsoft Entra ID | Synchronize users and groups, support identity lifecycle processes, and enrich ServiceNow User records with authoritative directory data. | Microsoft Entra ID → Martini → ServiceNow | A scheduled Martini workflow retrieves changed directory users and groups, normalizes identity attributes, matches stable identifiers, and creates or updates ServiceNow Users while routing authorization and validation failures for review. |
| Jira Software | Link development issues with ServiceNow Incidents, Problems, and Change Requests for coordinated IT service and development processes. | ServiceNow → Martini → Jira Software | Martini maps ServiceNow records to Jira issues, applies routing rules based on service and assignment data, stores cross-system identifiers, and synchronizes selected lifecycle updates without creating duplicates. |
| Workday | Synchronize employee and organizational data with ServiceNow Users, departments, ownership fields, and service-management processes. | Workday → Martini → ServiceNow | Martini consumes Workday changes, transforms organizational and employee attributes to the ServiceNow User model, validates required references, and processes the feed incrementally using a persisted checkpoint. |
| Microsoft Teams | Send incident or approval notifications and support collaboration around ServiceNow records, with optional action callbacks. | ServiceNow → Martini → Microsoft Teams | ServiceNow calls a Martini API through a configured outbound integration, Martini applies notification and severity rules, formats the message for Teams, and optionally receives callback data for controlled workflow updates. |
| Splunk | Create or update ServiceNow Incidents from operational alerts and associate incidents with monitoring events. | Splunk → Martini → ServiceNow | Martini receives or retrieves alert payloads, normalizes source and severity fields, deduplicates on an alert correlation key, and creates or updates ServiceNow Incidents through the Table API. |
| Datadog | Route monitoring alerts to ServiceNow for incident management and synchronize selected status or acknowledgment information. | Datadog → Martini → ServiceNow | A Martini API receives supported Datadog notifications, validates the event, applies routing and suppression rules, and writes the resulting Incident to ServiceNow with retry and duplicate-prevention controls. |
| NetSuite | Synchronize service requests, customer context, assets, or fulfillment-related information across ITSM and ERP processes. | NetSuite → Martini → ServiceNow | Martini orchestrates REST-based retrieval and update flows, maps NetSuite business identifiers to ServiceNow references, applies record ownership rules, and persists correlation IDs for bidirectional synchronization. |
How to build a ServiceNow integration in Martini
Objective
Establish controlled access to the ServiceNow instance and the downstream systems involved in the integration.
Instructions in Martini
- Confirm the target ServiceNow release, instance URL, API surface, and required table or field permissions.
- Choose OAuth 2.0, Basic Authentication, API keys, or mutual TLS according to the instance policy.
- Store credentials, tokens, and certificates as protected Martini environment configuration or secrets.
- Use least-privilege integration accounts and separate credentials for appropriate environments.
Objective
Select the event-driven or scheduled entry point that matches the ServiceNow process and required freshness.
Instructions in Martini
- Use a Martini API when ServiceNow will call an outbound REST endpoint, business-rule callback, or flow action.
- Use a scheduler for incremental synchronization based on sys_updated_on or another validated modification field.
- Define the event or polling scope explicitly because ServiceNow does not provide a universal webhook stream for every table and event.
- Set page sizes, concurrency, and polling intervals to protect the ServiceNow instance.
Objective
Acquire ServiceNow records, attachments, or callback payloads in a controlled and resumable manner.
Instructions in Martini
- Query only the required fields and use encoded queries, time windows, pagination, and stable identifiers where supported.
- Retrieve related reference data such as caller, assignment group, service, and Configuration Item when the target requires it.
- Process attachments separately from parent record fields and account for binary content and size limits.
- Persist a checkpoint or high-water mark after successful processing when synchronization must resume reliably.
Objective
Coordinate the end-to-end process across ServiceNow, Martini, and target systems.
Instructions in Martini
- Separate retrieval, validation, transformation, target delivery, and checkpointing into clear workflow stages.
- Branch authentication, ACL, validation, throttling, transient, and permanent failures differently.
- Use reusable workflow logic for common ServiceNow reference resolution, correlation, and response handling.
- Return controlled acknowledgments for inbound callbacks while continuing asynchronous work when appropriate.
Objective
Convert ServiceNow payloads and reference fields into a stable canonical or target-specific model.
Instructions in Martini
- Map actual objects such as Incident, Change Request, User, Configuration Item, and Knowledge Article explicitly.
- Normalize dates, time zones, choice values, display values, sys_id values, and external identifiers.
- Resolve whether each target expects a ServiceNow sys_id, display value, or another unique key.
- Handle JSON, XML, and attachment metadata according to the selected API.
Objective
Enforce data quality, routing, ownership, deduplication, and update-direction decisions before writing data.
Instructions in Martini
- Validate required fields and permitted choice values before making downstream calls.
- Use sys_id, external IDs, or correlation identifiers to distinguish creates from updates.
- Apply assignment, severity, approval, publication, and suppression rules in the workflow rather than duplicating them across point-to-point scripts.
- Route rejected records to a review or remediation path with actionable error context.
Common ServiceNow data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Incident | Tracks interruptions or degradation of an IT or business service and is commonly created, updated, or synchronized from monitoring and support applications. | Salesforce, Splunk, Datadog, Microsoft Teams, Jira Software, reporting platforms | Martini queries changed Incidents, resolves caller, assignment, service, and configuration-item references, maps fields to a canonical incident model, and uses sys_id or an external correlation key for idempotent updates. |
| Problem | Tracks the underlying causes of one or more Incidents and supports problem-management coordination with development or operations teams. | Jira Software, reporting platforms, knowledge systems | Martini maps problem identifiers, descriptions, ownership, status, and related Incident references, then applies validation and controlled update rules. |
| Change Request | Coordinates planned changes, approvals, implementation, risk, and completion status across service-management and deployment processes. | Jira Software, deployment platforms, Microsoft Teams, project-management applications | Martini can receive or retrieve Change Requests, validate approval and risk fields, call downstream deployment APIs, and write implementation results back to ServiceNow. |
| User | Represents an employee, agent, service account, or other individual used in ownership, caller, approval, and assignment relationships. | Microsoft Entra ID, Workday, Salesforce, identity governance applications | Martini synchronizes authoritative identity attributes, resolves stable identifiers, and respects ServiceNow roles, ACLs, field permissions, and reference-field requirements. |
| Configuration Item | Represents an infrastructure component, application, service, or other managed item in the CMDB. | Datadog, Splunk, inventory platforms, procurement applications, analytics systems | Martini processes Configuration Items incrementally, maps class and ownership data, resolves related references, and routes schema or authorization errors separately from transient failures. |
| Knowledge Article | Stores published support and operational knowledge for service agents, employees, and connected support processes. | Salesforce, Microsoft Teams, portals, enterprise search and knowledge applications | Martini can retrieve or publish selected article data through supported ServiceNow APIs, transform content and metadata, and apply publication-state and duplicate checks. |
Authentication and security considerations
Authentication and authorization
ServiceNow supports Basic Authentication, OAuth 2.0, selected API-key scenarios, and mutual TLS according to instance configuration. Access is further controlled by integration-user roles, table and field ACLs, OAuth scopes, web-service access controls, application scope, and cross-scope rules.
Martini should use protected environment-managed secrets for credentials, tokens, and certificates. Integration accounts should follow least-privilege principles and be validated separately in development, testing, and production environments.
- Confirm the ServiceNow release, API, roles, ACLs, and OAuth scopes before implementation.
- Do not embed credentials or tokens in mappings, payloads, or source-controlled workflow definitions.
- Separate authentication failures from authorization and field-level access failures.
Operational considerations for ServiceNow integrations
Reliability and scale
Use narrow encoded queries, field selection where supported, pagination, incremental filters, and checkpoints instead of repeatedly scanning large ServiceNow tables. Control concurrency and apply backoff because instances can enforce request limits, transaction quotas, and protection against excessive activity.
Data integrity
Use sys_id, external identifiers, or correlation keys to make retries idempotent and prevent duplicate Incidents, Change Requests, or other objects. Resolve reference fields deliberately because a target operation may require a sys_id rather than a display value.
Change and failure management
ServiceNow instances may contain custom tables, fields, business rules, scoped applications, scripted endpoints, and release-specific behavior. Test against the target instance and handle ACL failures, validation errors, throttling, transient server errors, attachment limits, schema changes, and date-time differences separately.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Point-to-point scripts often duplicate authentication, pagination, transformation, retry, and monitoring logic. Martini provides a workflow-based place to coordinate ServiceNow with APIs, files, databases, messaging systems, and other applications.
Maintainable integration logic
Martini separates API consumption, mapping, validation, business rules, error handling, and environment configuration. This makes ServiceNow-specific assumptions visible and reusable while preserving the flexibility to handle custom tables, scripted APIs, SOAP services, and attachments.
Controlled enterprise delivery
Martini can expose API façades, process callbacks, run scheduled synchronizations, persist checkpoints, and route failures for investigation. The result is a more controlled integration boundary than a collection of unmanaged scripts or tightly coupled point-to-point calls.
Frequently asked questions
ServiceNow can be integrated through its REST APIs, including the Table API, Import Set API, Attachment API, scripted REST resources, and product-specific APIs. SOAP web services support WSDL-based and legacy integrations, while outbound REST messages, business rules, flows, and event mechanisms can call external endpoints for configured processes. Import Sets, filtered queries, pagination, exports, and attachment operations support batch and file-based scenarios.
Yes. Martini can consume ServiceNow REST APIs, consume SOAP services where required, receive requests from configured ServiceNow outbound integrations, and orchestrate workflows for synchronization, transformation, validation, attachments, retries, and idempotency. No native Martini ServiceNow connector is documented in the supplied materials.
No. A dedicated ServiceNow connector is not required. Martini can use ServiceNow’s confirmed native REST APIs, SOAP services, Import Set and attachment endpoints, authentication methods, and configured outbound callback mechanisms through standards-based API consumption and workflow orchestration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate ServiceNow. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from ServiceNow, cloud infrastructure, or other third-party systems depending on subscription, usage, licensing, and deployment model.
REST is generally the preferred starting point for new ServiceNow integrations, including the Table API, Import Set API, Attachment API, scripted REST resources, and relevant product APIs. SOAP remains appropriate for WSDL-based systems and established legacy interfaces. Outbound REST messages and configured flows or business rules are suitable when ServiceNow needs to call Martini.
Martini can receive requests when the ServiceNow instance is configured to call a Martini REST endpoint through an outbound REST message, business rule, flow, or another supported callback mechanism. This is configuration-dependent and should not be treated as a universal webhook feed for every ServiceNow table or event.
A Martini workflow can use modification-time filters such as sys_updated_on, stable identifiers such as sys_id, pagination, and a persisted checkpoint or high-water mark. The workflow processes successful pages incrementally and can retry failed work without reprocessing the entire table.
Yes. Martini can call ServiceNow attachment endpoints, handle binary content and metadata, and deliver files to another supported endpoint or storage system. Martini can also expose a controlled REST API façade that hides ServiceNow-specific fields, applies authorization and business rules, and orchestrates calls to ServiceNow and other enterprise systems.
Related Martini documentation
API integration
Workflows
Connect ServiceNow with your enterprise systems
Use Martini to build maintainable ServiceNow integrations across APIs, callbacks, workflows, files, and enterprise applications.