Ellipse Gradient for Header

Ivanti Neurons Integration Guide

Integrate Ivanti Neurons services with enterprise applications through product-specific REST APIs, selected outbound notifications, scheduled workflows, and controlled data mappings.

Ivanti Neurons integration options at a glance

Ivanti Neurons is a product family, so available integration mechanisms depend on the target service, tenant, API version, and permissions. REST APIs are the principal option for Neurons services and Neurons for ITSM, supporting objects such as Incidents, Service Requests, Changes, Problems, Configuration Items, and Knowledge Articles. Selected configurations can issue outbound notifications or web-service callbacks, while scheduled polling supports incremental synchronization where suitable filters are available. ITSM records may also expose attachment operations. Authentication can involve OAuth 2.0, tenant-specific API credentials, or session and bearer tokens. Martini can consume these APIs, receive selected callbacks, transform payloads, apply business rules, and orchestrate reliable workflows.

Integration pointSupported by Ivanti Neurons?Common use casesHow Martini supports it
REST APIsYesCreate and update Incidents and Service Requests, and query Problems, Changes, Configuration Items, Knowledge Articles, and service-specific endpoint data where enabled.Martini can consume Ivanti REST endpoints from workflows, map request and response payloads, apply business rules, and expose a separate normalized Martini API.
Webhooks / outbound callbacksLimitedSelected ITSM business rules or Neurons configurations can invoke external web services or issue outbound notifications for supported events.Martini can expose an API endpoint to receive selected callbacks, validate payloads, retrieve the current Ivanti object when needed, and process the event idempotently.
SOAP APIsLegacyOlder Ivanti service-management integrations or product interfaces may use SOAP or web-service operations, although REST is preferred for new Neurons work.Martini can consume SOAP services when a specific Ivanti deployment requires them, while keeping the integration isolated as a legacy interface.
File / attachment APIsLimitedApplicable Neurons for ITSM records can support attachment-related operations, subject to object, API version, file type, and tenant constraints.Martini can orchestrate parent-object creation followed by attachment transfer, with separate validation, size handling, retry, and malware-scanning considerations.
AuthenticationLimitedAuthentication varies by service and may include OAuth 2.0, tenant-specific API credentials, or session and bearer token authorization for ITSM APIs.Martini can keep tenant identifiers, credentials, tokens, and endpoint configuration in environment-specific secure configuration rather than workflow payloads.
Scheduled synchronizationYesPolling can support incremental synchronization where APIs provide last-modified, status, sequence, or comparable filters.Martini can run scheduled workflows with pagination, overlap windows, persisted watermarks, idempotent upserts, and reconciliation handling.
Bulk / asynchronous APIsNot confirmedSome Neurons services may expose batch or asynchronous operations, but no uniform portfolio-wide capability was verified.Martini can implement controlled paging and batching over ordinary REST operations where the specific API supports those patterns, without assuming a vendor bulk API.

How Ivanti Neurons exposes data and business events

Ivanti Neurons REST APIs

REST is the principal integration mechanism for Ivanti Neurons cloud services and Neurons for ITSM. Available resources, operations, fields, authentication, and permissions vary by product, API version, and tenant. REST operations can cover Incidents, Service Requests, Problems, Changes, Configuration Items, Knowledge Articles, and other service-specific objects.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to the applicable Ivanti service, calls the required REST endpoint, handles pagination and response validation, maps the result to a canonical or target model, and applies business rules before writing to downstream systems or returning a response through a Martini API.

Implementation sequence

Authenticate using the method configured for the target Neurons service
Receive an API request or start the workflow from a schedule
Call the applicable Ivanti REST resource
Continue through all paginated responses
Validate and map the Ivanti object
Apply business rules and idempotency checks603;

Common Ivanti Neurons integration patterns

Pattern 1: Create Ivanti incidents from external cases

When to use this pattern

Use this pattern when Salesforce, an internal portal, or another application needs to create Ivanti Incidents or Service Requests and receive the resulting Ivanti identifier and status. It centralizes validation, field mapping, and duplicate prevention before data reaches the ITSM tenant.

Integration direction
Salesforce
Martini
Ivanti Neurons
Example Mapping
Ivanti Neurons FieldCanonical FieldTarget Field
CaseNumberexternalReferenceExternal Reference
SubjectsummarySubject
DescriptiondescriptionDescription
PrioritypriorityPriority
Martini implementation pattern

Martini exposes or consumes an API, validates the source payload, maps case fields to the Ivanti object model, applies routing and required-field rules, and creates the object through REST. The workflow stores the Ivanti identifier and correlation key, returns the result to the source, and separates validation, authorization, throttling, and transient failures for appropriate handling.

Martini capabilities used
  • APIs
  • workflows
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize Ivanti ITSM objects to enterprise systems

When to use this pattern

Use this pattern for scheduled synchronization of Incidents, Problems, Changes, or Configuration Items to a data warehouse, reporting platform, or another service-management environment. It is suitable when no reliable event notification exists for the required object or event.

Integration direction
Ivanti Neurons
Martini
ServiceNow
Example Mapping
Ivanti Neurons FieldCanonical FieldTarget Field
IncidentNumberticketNumberNumber
StatuslifecycleStatusState
LastModifiedDateupdatedAtUpdated
ConfigurationItemrelatedAssetConfiguration item
Martini implementation pattern

A scheduled Martini workflow queries Ivanti using an incremental filter and overlap interval, follows pagination, normalizes object and status values, and upserts the target using a stable correlation key. The workflow persists a watermark only after successful processing, records partial failures, and includes reconciliation for missed or late updates.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination handling
  • data mapping
  • idempotency
  • monitoring

Pattern 3: Process selected Ivanti outbound notifications

When to use this pattern

Use this pattern when the specific Neurons service or ITSM business rule can issue an outbound notification for a required event. It avoids polling for supported events while recognizing that callback coverage, payload completeness, retries, and signatures must be confirmed.

Integration direction
Ivanti Neurons
Martini
Microsoft Teams
Example Mapping
Ivanti Neurons FieldCanonical FieldTarget Field
ObjectIdsourceObjectIdCorrelation ID
EventTypeeventTypeNotification type
StatuslifecycleStatusMessage status
SummarysubjectNotification title
Martini implementation pattern

Martini exposes a controlled API endpoint to receive the callback, validates the source and event shape, and uses the object identifier to retrieve the current Ivanti resource when the notification is incomplete. It applies event filtering and duplicate detection before publishing a downstream notification, with safe acknowledgment and retry handling.

Martini capabilities used
  • API exposure
  • webhook reception
  • workflows
  • validation
  • business rules
  • error handling

Pattern 4: Coordinate service request fulfillment

When to use this pattern

Use this pattern for employee lifecycle, access, equipment, or other fulfillment processes in which an Ivanti Service Request must coordinate with Workday, Microsoft Entra ID, or another authorized downstream system.

Integration direction
Ivanti Neurons
Martini
Microsoft Entra ID
Example Mapping
Ivanti Neurons FieldCanonical FieldTarget Field
RequestedForemployeeIdUser ID
RequestOfferingrequestTypeFulfillment operation
ApprovalStatusapprovalStateApproval state
RequestStatusfulfillmentStatusOperation status
Martini implementation pattern

Martini receives or polls eligible Service Requests, validates approval and entitlement conditions, maps request data to the downstream API, and invokes only permitted fulfillment operations. It updates Ivanti with success or failure details, uses correlation identifiers for safe retries, and routes unresolved exceptions for operational review.

Martini capabilities used
  • workflows
  • API orchestration
  • data transformation
  • business rules
  • retry handling
  • audit logging

Applications commonly integrated with Ivanti Neurons

Ivanti Neurons can be connected with adjacent enterprise applications when organizations need to coordinate service management, identity, endpoint, collaboration, development, or employee-lifecycle processes. These relationships are implementation patterns rather than claims of native Ivanti pairings; each target service and permission model should be validated before delivery.

Application Scenario Direction Martini Pattern
Salesforce Synchronize customer support cases, account context, and service-impact information with Ivanti Incidents and Service Requests. Salesforce → Martini → Ivanti Neurons Martini receives case events or scheduled extracts from Salesforce, validates and maps them to Ivanti Incidents or Service Requests, then returns Ivanti identifiers and status updates to Salesforce. Correlation IDs and idempotent upserts help prevent duplicate tickets.
ServiceNow Exchange incidents, changes, configuration data, or migration records between two service-management environments during coexistence or transition. ServiceNow → Martini → Ivanti Neurons Martini consumes APIs from both platforms, maps object and status models through a canonical structure, applies loop-prevention rules, and synchronizes only eligible changes. Failed records are retried separately with correlation and audit details.
Microsoft Entra ID Provide identity and group context for access-related Service Requests and coordinate approved fulfillment actions. Microsoft Entra ID → Martini → Ivanti Neurons A Martini workflow receives an employee or access event, validates identity attributes, creates or updates an Ivanti Service Request, and optionally invokes an approved downstream action. The result and correlation identifier are written back to Ivanti.
Workday Support onboarding, transfer, and offboarding processes by creating Ivanti requests and coordinating fulfillment activities. Workday → Martini → Ivanti Neurons Martini consumes lifecycle data from Workday, maps worker and employment attributes to an Ivanti Service Request, routes fulfillment to authorized systems, and updates the request with completion or exception status.
Microsoft Intune Reconcile endpoint and compliance context or coordinate device-management processes across endpoint platforms. Microsoft Intune → Martini → Ivanti Neurons Martini retrieves permitted device or compliance data from the relevant APIs, normalizes identifiers and statuses, and updates Ivanti objects or downstream records. Product-specific endpoint operations are enabled only after validating the target Neurons service and permissions.
Jira Synchronize engineering work with Ivanti Incidents, Problems, and Changes. Jira → Martini → Ivanti Neurons Martini maps Jira issues and Ivanti objects through a shared correlation model, routes only approved status transitions, and prevents update loops. Retries and validation failures are isolated so one malformed issue does not stop the broader synchronization.
Microsoft Teams Create or update Ivanti tickets from operational notifications and collaboration processes, and publish Ivanti status updates to teams. Microsoft Teams → Martini → Ivanti Neurons Martini receives an approved collaboration event or intermediary notification, validates the request, creates or updates an Ivanti object, and sends a summarized result back to the relevant Teams workflow or channel integration.
NetSuite Coordinate asset, procurement, or fulfillment information where Ivanti Configuration Items or Service Requests require financial or reference data. NetSuite → Martini → Ivanti Neurons Martini retrieves selected NetSuite reference data, maps it to Ivanti Configuration Items or Service Requests, applies ownership and eligibility rules, and records downstream results with an external correlation key.

How to build a Ivanti Neurons integration in Martini

Objective

Identify the exact Neurons service, tenant, API version, object model, and authentication method before building the workflow.

Instructions in Martini

  • Confirm whether the target is Neurons for ITSM, UEM, Discovery, DEX, or another service.
  • Configure OAuth 2.0, API credentials, or session and bearer token handling as required by the target API.
  • Store tenant identifiers, secrets, tokens, and endpoint configuration in environment-specific secure configuration.

Objective

Select an event-driven, API-led, or scheduled entry point based on the availability and reliability of the required Ivanti event capability.

Instructions in Martini

  • Use a Martini API endpoint for source-driven intake or selected Ivanti callbacks.
  • Use a scheduler when polling is required for incremental synchronization.
  • Document the selected object and event coverage rather than assuming universal webhook support.

Objective

Receive the source payload or retrieve the current Ivanti resource with complete pagination and response validation.

Instructions in Martini

  • Call the applicable Ivanti REST resource.
  • Follow next-page indicators until the result set is complete.
  • Retrieve the current object after a callback when the event contains only an identifier.
  • Capture sanitized response metadata and correlation identifiers.

Objective

Coordinate Ivanti calls, downstream APIs, conditions, and state transitions in a maintainable Martini workflow.

Instructions in Martini

  • Separate intake, validation, lookup, transformation, write, and completion stages.
  • Apply routing rules for Incidents, Service Requests, Changes, and other supported objects.
  • Persist a watermark or processing state only after the relevant work succeeds.

Objective

Convert Ivanti-specific fields, statuses, identifiers, and custom attributes into the canonical or target application model.

Instructions in Martini

  • Map required fields and preserve stable external identifiers.
  • Normalize status, priority, ownership, and date values.
  • Handle tenant-specific custom fields without failing the entire synchronization when optional fields change.

Objective

Prevent duplicate records, unsafe updates, integration loops, and unintended ITSM business-rule side effects.

Instructions in Martini

  • Use correlation IDs or composite keys for idempotent upserts.
  • Prefer partial updates when supported rather than replacing full objects.
  • Check approval, entitlement, and status-transition conditions before fulfillment actions.

Common Ivanti Neurons data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
IncidentsCapture user-reported or system-detected issues and coordinate investigation, assignment, status, and resolution.Salesforce, ServiceNow, Jira, Microsoft Teams, data warehousesMartini validates required fields, maps source identifiers and priority values, creates or updates Incidents through REST APIs, and stores correlation and retry details.
Service RequestsRepresent requests for services, access, equipment, or fulfillment activities.Workday, Microsoft Entra ID, Salesforce, asset and fulfillment platformsMartini maps request and employee context, applies approval and routing rules, orchestrates downstream fulfillment, and writes the outcome back to Ivanti.
ProblemsTrack underlying causes associated with one or more Incidents.ServiceNow, Jira, reporting platforms, data warehousesMartini retrieves or synchronizes Problems, normalizes relationships and statuses, and prevents duplicate updates using stable external identifiers.
ChangesManage planned modifications to infrastructure, applications, or services.ServiceNow, Jira, endpoint-management platforms, reporting systemsMartini applies change eligibility and status-transition rules, maps implementation details, and handles retries without repeating an approved operation.
Configuration ItemsRepresent managed assets or components in the configuration management database.Microsoft Intune, NetSuite, ServiceNow, data warehousesMartini reconciles identifiers and attributes, processes paginated results, applies upsert logic, and preserves tenant-specific custom-field mappings.
Knowledge ArticlesProvide support and self-service content for employees and service agents.Portals, search platforms, reporting systems, collaboration applicationsMartini can query and transform article data through available REST resources, applying publication and ownership rules before downstream distribution.

Authentication and security considerations

Product-specific authentication

Ivanti Neurons authentication varies by service and tenant. OAuth 2.0, tenant-specific API credentials, and session or bearer token authorization may apply.

Credential protection

Martini should keep client secrets, tokens, tenant identifiers, and endpoint configuration in environment-specific secure configuration rather than embedding them in workflows or payloads.

Least privilege and transport security

Use HTTPS and limit API clients, roles, and object permissions to the operations required by the integration. Confirm scopes and permissions against the target Neurons service before deployment.

Operational considerations for Ivanti Neurons integrations

Pagination and throttling

List operations may paginate results, and tenant-specific quotas or concurrency limits may apply. Workflows should follow page indicators, control request rates, and use backoff for temporary throttling.

Idempotency and retries

Use stable external identifiers, correlation IDs, and overlap windows for safe upserts. Before retrying a timed-out create, determine whether Ivanti may already have accepted the request.

Business rules and side effects

ITSM updates can trigger approvals, assignments, notifications, SLAs, automations, or outbound actions. Test these effects in a non-production tenant and prevent integration loops.

Schema and attachments

Tenants may contain custom fields, statuses, layouts, and business rules. Treat attachment transfer as a separate path and validate file size, content type, encoding, permissions, and retry behavior.

Testing and observability

Capture sanitized HTTP status, endpoint, object type, object identifier, correlation ID, and response details. Test authentication, pagination, partial updates, callbacks, duplicate handling, and reconciliation before production release.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Ivanti APIs, callbacks, schedules, downstream applications, transformations, and business rules in workflows rather than scattering logic across scripts.

Reusable integration assets

Teams can expose controlled Martini APIs, reuse mappings and workflow logic, and adapt to differences between Neurons products, tenants, and target systems.

Operational reliability

Martini provides structured handling for pagination, validation, retries, idempotency, monitoring, and environment-specific configuration. This makes synchronization behavior easier to operate and change than isolated point-to-point scripts.

Frequently asked questions

How can Ivanti Neurons be integrated with enterprise systems?

Ivanti Neurons can be integrated primarily through product-specific REST APIs. Selected services and ITSM configurations can also issue outbound notifications or web-service callbacks, while scheduled polling supports incremental synchronization where suitable filters are available. Authentication and available objects vary by Neurons product and tenant.

Can Martini integrate with Ivanti Neurons?

Yes. Martini can consume Ivanti Neurons REST APIs, receive selected outbound callbacks through a Martini API, run scheduled synchronization workflows, transform Ivanti objects, and coordinate downstream systems. The exact implementation depends on the target Neurons service and its authentication and permission model.

Do I need a connector to integrate Ivanti Neurons with Martini?

No. A dedicated Ivanti Neurons connector is not required. Martini can use Ivanti's confirmed native integration mechanisms, including product-specific REST APIs, selected outbound notifications, callbacks, scheduled polling, and applicable attachment operations.

Is there any extra Lonti cost to integrate Ivanti Neurons with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Ivanti Neurons. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Ivanti, cloud infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.

Which Ivanti Neurons integration method should be used?

Use the REST API documented for the specific Neurons service and tenant. REST is the principal and recommended mechanism for new integrations. Selected callbacks can support event-driven processing, while scheduled polling is appropriate when the required event is unavailable. SOAP should generally be limited to legacy interfaces.

Are Ivanti Neurons webhooks or callbacks available?

Selected Ivanti configurations can issue outbound notifications or web-service callbacks, often through ITSM business rules or service-specific settings. Coverage is not universal across objects and events, so confirm payload completeness, transaction timing, retry behavior, signatures, and delivery status before relying on callbacks.

How does synchronization with Ivanti Neurons work?

Synchronization can use REST queries filtered by last-modified time, status, or another supported cursor, selected event notifications, or periodic reconciliation. Martini can paginate results, maintain a watermark with an overlap interval, map fields to target models, and use correlation keys and idempotent upserts to prevent duplicates.

How does Martini handle Ivanti errors, retries, and duplicate records?

Martini can classify authentication, authorization, validation, throttling, transient server, and malformed-payload failures, then apply suitable retry or exception paths. Stable external identifiers and correlation IDs support idempotency. Timed-out creates should be checked before retrying because the original operation may have succeeded.

Related Martini documentation

API Integration

Workflows

Data Handling

Security Operations

Connect Ivanti Neurons with your enterprise systems

Use Martini to design reliable Ivanti Neurons integrations around the APIs, callbacks, authentication methods, and workflow requirements of your specific Neurons service.

EXPLORE MARTINI
BOOK A DEMO