.png)
ServiceNow IT Operations Management Integration Guide
Integrate ServiceNow ITOM with enterprise systems through REST and SOAP APIs, configured outbound callbacks, scheduled workflows, and controlled data synchronization.
ServiceNow IT Operations Management integration options at a glance
ServiceNow ITOM provides REST APIs for Table, Import Set, Attachment, and application-specific operations, with SOAP services available for legacy or WSDL-based integrations. Configured outbound REST messages, notifications, business rules, scripts, and application-specific mechanisms can provide callback-style event delivery, although there is no universal webhook stream for every ITOM object. Import Sets, pagination, scheduled jobs, and batch capabilities support higher-volume synchronization. Martini can consume these APIs, receive callbacks through exposed APIs, transform ServiceNow JSON or XML, apply validation and idempotency rules, and orchestrate reliable workflows using environment-specific authentication and secrets.
| Integration point | Supported by ServiceNow IT Operations Management? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Use the Table API for Configuration Items, CI relationships, Events, Alerts, Incidents, and other permitted tables. The Import Set, Attachment, scripted REST, and application-specific APIs support specialized operations. | Martini can consume ServiceNow REST endpoints from workflows, handle pagination and encoded queries, transform JSON, and expose APIs for downstream systems. |
| SOAP APIs | Yes | SOAP web services provide table access and scripted SOAP services for WSDL-based contracts and existing legacy integrations. | Martini can consume SOAP services, configure authentication, map XML responses, and apply workflow error handling. REST is generally preferable for new integrations when available. |
| Webhooks / outbound callbacks | Limited | ServiceNow can invoke external endpoints through outbound REST messages, notifications, business rules, scripts, Flow Designer or IntegrationHub actions, and application-specific mechanisms. | Martini can expose an API endpoint to receive configured callbacks, validate payloads, deduplicate events, and trigger follow-on workflows. Coverage depends on ServiceNow configuration. |
| Bulk, asynchronous, and batch APIs | Yes | Import Set APIs, asynchronous imports, scheduled jobs, transform maps, pagination, and REST batch capabilities support higher-volume movement where enabled by the release and instance. | Martini can orchestrate batch workflows, split or aggregate payloads, control concurrency, checkpoint progress, and route failed records for review. |
| File / attachment APIs | Yes | Attachment APIs upload, download, and manage files associated with Incidents, Configuration Items, knowledge records, and other supported records. | Martini can retrieve or upload attachments as part of a workflow while preserving record identifiers and validating content type, size, and access requirements. |
| Authentication | Yes | ServiceNow supports OAuth 2.0 and Basic Authentication for applicable REST and SOAP integrations. Roles, ACLs, scopes, application policies, and instance security determine effective access. | Martini can configure authenticated API consumption and store credentials or tokens in environment-specific secrets rather than workflow mappings. |
| Database access | No | Direct SQL access to a ServiceNow production instance is not the normal integration mechanism. Supported APIs and documented export facilities should be used instead. | Martini can integrate through ServiceNow APIs or a separately documented export endpoint, but should not be positioned as connecting directly to the ServiceNow database. |
How ServiceNow IT Operations Management exposes data and business events
ServiceNow REST APIs
ServiceNow REST APIs, including the Table API, Import Set API, Attachment API, scripted REST APIs, and application-specific resources, provide the primary integration surface for ITOM data. Availability depends on the instance release, plugins, roles, ACLs, and application scope.
Martini implementation pattern
Martini implementation pattern: a workflow calls the required ServiceNow REST endpoint, sends bounded queries and pagination parameters, maps the JSON response into a canonical model, applies business rules, and writes the result to one or more target systems. For inbound processing, Martini can expose a controlled API that receives normalized data and submits it to ServiceNow.
Implementation sequence
ServiceNow SOAP APIs
ServiceNow supports SOAP web services for table access and scripted SOAP services. SOAP remains relevant for WSDL-based enterprise contracts and existing integrations, although REST is generally preferred for new work where the required capability is available.
Martini implementation pattern
Martini implementation pattern: a workflow consumes the WSDL-based operation, maps XML requests and responses, applies the same validation and retry policies used for REST, and converts the result to a canonical model or downstream format.
Implementation sequence
ServiceNow outbound callbacks
ServiceNow can send callback-style notifications through outbound REST messages, notifications, business rules, scripts, Flow Designer or IntegrationHub actions, and application-specific integrations. This is partial and configuration-dependent rather than a universal webhook stream.
Martini implementation pattern
Martini implementation pattern: Martini exposes an authenticated API endpoint, receives the configured ServiceNow notification, validates the event and source, applies deduplication and filtering, and starts an asynchronous workflow. The workflow can retrieve the current ServiceNow record before acting when the callback payload is incomplete.
Implementation sequence
Import, batch, and scheduled synchronization
ServiceNow supports Import Set processing, scheduled jobs, transform maps, pagination, asynchronous approaches, and REST batch capabilities subject to release and configuration. These mechanisms are useful for CMDB, infrastructure, and high-volume data movement.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a bounded workflow, retrieves changed records or prepares an Import Set payload, controls concurrency, validates batches, and stores a compound checkpoint such as sys_updated_on plus sys_id. Failed records are isolated without discarding successful work.
Implementation sequence
ServiceNow Attachment APIs
ServiceNow Attachment APIs support uploading, downloading, and managing files associated with supported records such as Incidents and Configuration Items. Binary handling, content types, size limits, retention, and ACLs must be validated for the target instance.
Martini implementation pattern
Martini implementation pattern: the workflow first identifies the parent record, calls the attachment endpoint separately from the record API, validates the binary response or upload content, and transfers the file to the target system with its ServiceNow identifiers and metadata.
Implementation sequence
Common ServiceNow IT Operations Management integration patterns
Pattern 1: Synchronize CMDB configuration items
When to use this pattern
Use this pattern when another platform needs a governed copy of ServiceNow infrastructure inventory. It is suitable for scheduled reconciliation of CIs and relationships where completeness, stable identifiers, and incremental processing matter more than immediate event delivery.
Integration direction
Example Mapping
| ServiceNow IT Operations Management Field | Canonical Field | Target Field |
|---|---|---|
| sys_id | sourceId | servicenow_ci_id |
| name | resourceName | asset_name |
| sys_class_name | resourceClass | asset_type |
| sys_updated_on | sourceUpdatedAt | updated_at |
Martini implementation pattern
A scheduled Martini workflow queries the relevant CMDB class with pagination and a bounded sys_updated_on plus sys_id checkpoint. It maps class-specific fields, validates required identifiers, deduplicates by sys_id, and writes changes to the warehouse. Transient API failures are retried with backoff, while invalid records are isolated for review.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- pagination and checkpointing
- data mapping
- validation
- error handling
Pattern 2: Forward ServiceNow alerts to PagerDuty
When to use this pattern
Use this pattern when Event Management alerts must reach on-call responders with consistent severity, service, and lifecycle handling. It avoids creating duplicate pages when ServiceNow retries or reprocesses an alert.
Integration direction
Example Mapping
| ServiceNow IT Operations Management Field | Canonical Field | Target Field |
|---|---|---|
| number | incidentReference | dedup_key |
| severity | priority | urgency |
| short_description | summary | title |
| cmdb_ci | configurationItem | custom_details.ci |
Martini implementation pattern
Martini receives a configured ServiceNow callback or polls Alert records, filters by state and severity, enriches the payload with CI or service information, and calls the PagerDuty API. The workflow stores the PagerDuty identifier, updates existing incidents rather than creating duplicates, and retries transient responses while routing rejected payloads to an error workflow.
Martini capabilities used
- API consumption
- exposed APIs
- event-driven workflows
- data mapping
- business rules
- idempotency
- retry and error handling
Pattern 3: Ingest monitoring events into ServiceNow ITOM
When to use this pattern
Use this pattern when monitoring platforms such as Datadog or Splunk need to create or update ServiceNow ITOM events, alerts, or incidents. It is useful for normalizing multiple monitoring schemas before they reach Event Management.
Integration direction
Example Mapping
| ServiceNow IT Operations Management Field | Canonical Field | Target Field |
|---|---|---|
| monitor_event_id | sourceEventId | correlation_id |
| alert_level | severity | severity |
| host | resourceName | node |
| message | description | description |
Martini implementation pattern
Martini exposes an authenticated API for monitoring notifications, identifies the source system, normalizes severity and timestamps, and looks up the matching CI when needed. It applies a deterministic idempotency key, submits the event through the appropriate ServiceNow endpoint, and uses dead-letter handling for validation or authorization failures.
Martini capabilities used
- exposed APIs
- webhook consumption
- JSON handling
- data transformation
- CI lookup
- business rules
- dead-letter and retry handling
Pattern 4: Export discovered infrastructure data
When to use this pattern
Use this pattern when security, compliance, asset, or cloud-management platforms require selected infrastructure data from ServiceNow Discovery and the CMDB. It limits the exported fields and retains ServiceNow identifiers for repeatable updates.
Integration direction
Example Mapping
| ServiceNow IT Operations Management Field | Canonical Field | Target Field |
|---|---|---|
| sys_id | sourceId | servicenow_resource_id |
| name | resourceName | resource_name |
| ip_address | networkAddress | ip_address |
| discovery_source | sourceSystem | discovery_source |
Martini implementation pattern
A scheduled workflow queries the appropriate CI child tables, applies field selection and class-specific mapping, and sends selected infrastructure data to the target platform. Martini preserves identifiers, applies an overlap window around the timestamp checkpoint, and records API, transformation, and target-write outcomes for reconciliation.
Martini capabilities used
- scheduled workflows
- REST API consumption
- pagination
- field mapping
- transformation
- checkpointing
- monitoring and error handling
Applications commonly integrated with ServiceNow IT Operations Management
ServiceNow ITOM can be integrated with monitoring, cloud, collaboration, engineering, and business applications. The exact direction and object coverage depend on the ServiceNow release, activated plugins, licensing, roles, and configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize operational incidents or service health with customer accounts, cases, and service operations. | ServiceNow IT Operations Management → Martini → Salesforce | Martini consumes ServiceNow Incident, Alert, or service-status data, maps it to Salesforce objects, and applies correlation and update rules. Salesforce case activity can be sent back through a separate workflow when required. |
| Jira Software | Connect operational incidents and alerts with engineering issues, defects, comments, and delivery status. | ServiceNow IT Operations Management → Martini → Jira Software | A Martini workflow maps ServiceNow incidents or alerts to Jira issues, preserves identifiers on both sides, and processes Jira status changes through API polling or configured callbacks. |
| PagerDuty | Route critical ITOM alerts to on-call responders and synchronize acknowledgement or resolution state. | ServiceNow IT Operations Management → Martini → PagerDuty | Martini filters alerts by severity and service, transforms them into PagerDuty requests, stores the external identifier, and reconciles lifecycle updates without creating duplicate incidents. |
| Splunk | Exchange infrastructure and event data for search, analytics, detection, and operational incident creation. | Splunk → Martini → ServiceNow IT Operations Management | Martini receives selected Splunk detections or events through an API, normalizes severity and CI references, and submits them to the appropriate ServiceNow Event Management or Import Set endpoint. |
| Datadog | Send monitoring alerts and service signals to ServiceNow ITOM while optionally synchronizing incident state back to monitoring operations. | Datadog → Martini → ServiceNow IT Operations Management | Martini exposes an API for Datadog notifications or consumes an available endpoint, performs CI lookup and severity normalization, then creates or updates ServiceNow events, alerts, or incidents. |
| Microsoft Azure | Reconcile Azure resources with the ServiceNow CMDB and process Azure Monitor alerts through ITOM Event Management. | Microsoft Azure → Martini → ServiceNow IT Operations Management | Scheduled Martini workflows retrieve Azure resource or monitoring data, map it to ServiceNow CI and event models, and use preserved identifiers and incremental checkpoints for repeatable updates. |
| Amazon Web Services | Populate the CMDB with AWS resources and route AWS monitoring events into ServiceNow ITOM. | Amazon Web Services → Martini → ServiceNow IT Operations Management | Martini consumes AWS inventory or monitoring payloads, applies account and resource mapping, submits changes through ServiceNow REST or Import Set APIs, and retries transient failures with controlled backoff. |
| Microsoft Entra ID | Provide identity, group, ownership, and assignment context for operational workflows and access-related processes. | Microsoft Entra ID → Martini → ServiceNow IT Operations Management | Martini periodically retrieves approved identity data, maps users and groups to ServiceNow reference fields, validates authorization boundaries, and updates only fields owned by the integration. |
How to build a ServiceNow IT Operations Management integration in Martini
Objective
Establish access to the target ServiceNow instance using an integration user or OAuth client with narrowly scoped roles and permissions.
Instructions in Martini
- Configure the ServiceNow REST or SOAP endpoint
- Select OAuth 2.0 where permitted by the instance policy, or use approved Basic Authentication
- Store client credentials, tokens, and passwords in Martini environment secrets
- Confirm table, field-level ACL, application-scope, and web-service permissions
Objective
Select an event, callback, API, or schedule that matches the required freshness and reliability characteristics.
Instructions in Martini
- Use a Martini API for configured ServiceNow callbacks
- Use a scheduler for CMDB and infrastructure reconciliation
- Use bounded polling when callback coverage is incomplete or configuration-dependent
- Define the event filter, polling window, and checkpoint strategy
Objective
Receive notifications or retrieve current ServiceNow records using stable queries and controlled result sizes.
Instructions in Martini
- Call the relevant Table, Import Set, Attachment, or application-specific API
- Use pagination, field selection, and bounded encoded queries
- Retrieve the current record when a callback contains only partial information
- Preserve sys_id, source event identifiers, and update timestamps
Objective
Coordinate retrieval, enrichment, transformation, target writes, and response handling in a maintainable Martini workflow.
Instructions in Martini
- Separate transport, mapping, business-rule, and persistence stages
- Enrich alerts with CI, relationship, service, or ownership data where required
- Control concurrency for ServiceNow instance health
- Use reusable workflow logic for common API and error operations
Objective
Convert ServiceNow tables, references, JSON, XML, or attachment metadata into the target application’s canonical model.
Instructions in Martini
- Map actual CI classes and child-table fields rather than assuming one universal schema
- Resolve reference fields using stable identifiers where possible
- Normalize severity, timestamps, states, and display values
- Validate required fields before submitting downstream data
Objective
Prevent duplicate work and ensure that only authorized, complete, and relevant ITOM data is propagated.
Instructions in Martini
- Use sys_id or source event identifiers as idempotency keys
- Apply severity, service, state, and ownership filters
- Respect CMDB identification and reconciliation ownership
- Separate create, update, retire, and delete behavior explicitly
Common ServiceNow IT Operations Management data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Configuration Items (CIs) | Synchronize servers, applications, databases, network devices, cloud resources, and other CMDB items. | Asset platforms, data warehouses, governance systems, security platforms, and cloud-management applications. | Martini queries the relevant cmdb_ci or child table, selects required fields, preserves sys_id, maps class-specific attributes, and uses incremental checkpoints and deduplication. |
| CI relationships | Represent dependencies between applications, hosts, databases, network components, and services. | CMDB replicas, service maps, governance platforms, and operational analytics stores. | Martini retrieves relationship data from the applicable relationship API, resolves referenced CI identifiers, validates endpoints, and writes relationships after the related CIs are available. |
| Events | Submit infrastructure or application signals to Event Management for processing and correlation. | ServiceNow Event Management, incident platforms, monitoring systems, and observability workflows. | Martini normalizes source-specific events, maps severity and CI references, applies idempotency keys, and submits events through the appropriate REST or Import Set API. |
| Alerts | Represent Event Management records created or updated after event processing and correlation. | PagerDuty, Jira Software, incident platforms, notification systems, and operational dashboards. | Martini filters alerts by state, severity, service, or CI, enriches them with relationship data, and creates or updates target incidents using stored external identifiers. |
| Incidents | Track operational work created from alerts or other ITOM processes. | Jira Software, Salesforce, PagerDuty, service operations platforms, and reporting systems. | Martini maps incident fields and references, separates create from update behavior, synchronizes lifecycle changes, and routes permanent validation failures to an error workflow. |
| MID Servers | Represent management, instrumentation, discovery, and integration servers used to reach infrastructure from ServiceNow. | Infrastructure inventory, compliance repositories, operational reporting, and governance platforms. | Martini reads MID Server records through permitted APIs, validates status and ownership fields, and distributes selected inventory data without assuming direct connectivity to the underlying infrastructure. |
Authentication and security considerations
Authentication and authorization
ServiceNow supports OAuth 2.0 and Basic Authentication for applicable REST and SOAP integrations. Certificate-based authentication may also be available in applicable deployments and security configurations.
- Use a dedicated integration user or OAuth client rather than a personal administrator account.
- Confirm roles, table permissions, field-level ACLs, web service access policies, application scopes, and OAuth scopes.
- Store credentials and tokens in Martini environment-specific secrets.
- Use least-privilege access and validate authorization against the target instance configuration.
Operational considerations for ServiceNow IT Operations Management integrations
Reliability and instance health
ServiceNow releases, plugins, application scopes, custom fields, ACLs, transaction quotas, and instance configuration can change the behavior of an integration.
- Use pagination, field selection, stable ordering, bounded filters, and incremental checkpoints.
- Use an overlap window and deduplicate by sys_id when synchronizing with sys_updated_on.
- Control concurrency and use backoff for 429, 5xx, timeout, and transient network errors.
- Prefer Import Set or batch patterns for high-volume ingestion instead of unbounded Table API calls.
- Validate CI classes, reference fields, relationships, custom fields, and identification and reconciliation ownership after upgrades.
- Treat attachments as separate binary operations and validate size, MIME type, ACL, retention, and scanning requirements.
- Capture HTTP status, ServiceNow error details, transaction identifiers, record identifiers, and correlation data for troubleshooting.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration delivery
Point-to-point scripts often combine authentication, transport, mapping, business rules, and operational handling in code that is difficult to reuse and govern. Martini provides a structured way to orchestrate ServiceNow workflows while retaining flexibility for custom integration logic.
- Consume REST or SOAP APIs and expose controlled APIs for callbacks or downstream consumers.
- Reuse workflows for pagination, checkpointing, validation, idempotency, and retry handling.
- Map ServiceNow CI classes, references, events, alerts, and incidents into canonical target models.
- Separate environment configuration and secrets from workflow definitions.
- Centralize error handling, monitoring, and operational routing instead of duplicating behavior across scripts.
Frequently asked questions
ServiceNow ITOM can be integrated through REST APIs such as the Table, Import Set, Attachment, scripted REST, and application-specific APIs. SOAP services support WSDL-based and legacy integrations. Configured outbound REST messages, notifications, business rules, scripts, and application-specific mechanisms can provide callback-style delivery, while scheduled and incremental API workflows support reliable synchronization.
Yes. No native Martini ServiceNow connector is documented in the supplied materials, but Martini can consume ServiceNow REST or SOAP APIs, receive configured callbacks through a Martini-exposed API, process attachments, and orchestrate mapping, validation, synchronization, and error handling.
No. A dedicated ServiceNow connector is not required. Martini can integrate using ServiceNow’s confirmed native REST and SOAP APIs, Import Set and Attachment APIs, configured outbound callbacks, and supported authentication methods.
Lonti does not charge an additional per-connector or per-vendor fee to integrate ServiceNow ITOM with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from ServiceNow, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
REST is generally preferred for new integrations when the required ServiceNow capability is available, particularly the Table, Import Set, Attachment, and application-specific APIs. SOAP remains appropriate for existing WSDL-based contracts or legacy deployments. GraphQL access was not confirmed and should not be assumed.
ServiceNow can invoke a Martini API through configured outbound REST messages, notifications, business rules, scripts, Flow Designer or IntegrationHub actions, and application-specific mechanisms. This is partial and configuration-dependent; ServiceNow does not provide one universal webhook stream for every ITOM object.
Martini can use scheduled or event-driven workflows to query Configuration Items, CI relationships, Alerts, Events, and Incidents. Pagination, bounded filters, an overlap window, and a compound checkpoint using sys_updated_on and sys_id help avoid missed or duplicated changes. Martini then maps and validates the data before writing it to the target system.
Martini can distinguish authorization, validation, throttling, timeout, transient platform, and not-found errors. It can retry transient failures with backoff, use sys_id or source event identifiers for idempotency, capture transaction and correlation data, and route permanently rejected records to an error workflow or operational queue.
Related Martini documentation
API Consumption
Data Processing
Security Operations
Build a maintainable ServiceNow ITOM integration
Use Martini to connect ServiceNow ITOM with enterprise applications through governed APIs, scheduled workflows, callbacks, data mapping, and operational error handling.