.png)
SolarWinds Integration Guide
Integrate SolarWinds Platform monitoring and SolarWinds Service Desk with enterprise systems through SWIS, REST APIs, alert actions, scheduled workflows, and controlled data synchronization.
SolarWinds integration options at a glance
SolarWinds integration depends on the product being connected. SolarWinds Platform primarily exposes the SolarWinds Information Service (SWIS) through REST/JSON interfaces and Orion SDK tooling for querying and managing monitoring entities such as Nodes, Interfaces, Alerts, and Events. SolarWinds Service Desk provides a separate REST API for Incidents, Requests, Changes, Assets, and related objects. Alert actions can provide HTTP callback-style delivery for selected configured alerts, while SOAP remains a legacy option for some Orion environments. Martini can authenticate securely, schedule filtered and paginated API calls, receive applicable callbacks, map product-specific objects, apply correlation rules, and synchronize results with enterprise applications.
| Integration point | Supported by SolarWinds? | Common use cases | How Martini supports it |
|---|---|---|---|
| SWIS REST/JSON APIs | Yes | Query and manipulate SolarWinds Platform entities such as Nodes, Interfaces, Volumes, Alerts, and Events. SWIS queries can support monitoring, inventory, administration, and reporting workflows. | Martini can consume the SWIS HTTP API, submit structured queries, paginate or filter results where available, transform responses, and orchestrate writes to other systems. |
| SolarWinds Service Desk REST API | Yes | Create, update, and retrieve Incidents, Requests, Problems, Changes, Users, Assets, Departments, Locations, and service catalog items subject to API version and permissions. | Martini can call the Service Desk REST API with token-style authentication, map objects to canonical models, and implement create-or-update synchronization workflows. |
| Webhooks / outbound callbacks | Limited | SolarWinds Platform alert actions can invoke configured HTTP-style actions in applicable deployments. This does not provide universal webhook coverage for every object or state transition. | Martini can expose an API or consume webhook-style notifications, validate the payload, correlate the alert, and run scheduled reconciliation for missed or unsupported events. |
| SOAP APIs | Legacy | Older Orion SDK materials and installations may expose SOAP-oriented SWIS interfaces for compatibility scenarios. REST/JSON is preferred for new work when supported by the target release. | Martini can consume documented SOAP services when a specific deployment requires them, while keeping the SOAP boundary isolated from the canonical workflow model. |
| File / attachment APIs | Limited | SolarWinds Service Desk includes object-specific attachment or file capabilities in some API contexts. Coverage and payload requirements depend on the endpoint and API version. | Martini can transform file content and metadata and call the documented attachment operation, with explicit validation for the target Service Desk endpoint. |
| Database / analytics access | Limited | SolarWinds Platform deployments use an underlying database and may support reporting or query scenarios. Direct database integration is deployment-dependent and should not replace supported API writes. | Martini can connect to an approved database using database workflows when required for specialized reporting, while treating the database schema as deployment-specific. |
| Authentication | Yes | SolarWinds Platform commonly uses SolarWinds or Windows/Active Directory-backed credentials with role-based permissions. SolarWinds Service Desk uses an API-token-style credential in request headers. | Martini can store credentials and tokens in environment-specific secrets, configure HTTPS requests, and use separate connection settings for Platform and Service Desk. |
| SDKs | Yes | The Orion SDK provides client libraries and examples, including PowerShell and .NET-oriented tooling, for interacting with SWIS. | Martini can use documented HTTP interfaces directly and can invoke custom JVM-compatible logic when a supported SDK or specialized client behavior is required. |
How SolarWinds exposes data and business events
SolarWinds SWIS REST APIs
SolarWinds Platform exposes SWIS HTTP interfaces for querying and manipulating entities in the Orion entity model. The available entities and operations depend on the installed modules, platform version, and account permissions.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow authenticates to SWIS, submits a filtered structured query, processes paginated results, maps the response to a canonical model, and writes to one or more target systems. The workflow can maintain checkpoints and distinguish transient transport failures from query or permission errors.
Implementation sequence
SolarWinds Service Desk REST API
SolarWinds Service Desk provides a separate REST API for service-management objects such as Incidents, Requests, Problems, Changes, Users, and Assets. Its authentication and object model are distinct from SWIS.
Martini implementation pattern
Martini implementation pattern: a workflow uses the Service Desk API token from secure environment configuration, retrieves or writes the selected object, transforms fields between Service Desk and the target application, and records the external identifier for idempotent updates.
Implementation sequence
SolarWinds Alert Actions
SolarWinds Platform alerting can invoke configured actions, including HTTP-style actions in applicable deployments. These actions should be validated for the installed version and configured alert coverage and should not be treated as universal webhooks.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured API or webhook endpoint for applicable alert actions, validates and normalizes the notification, correlates the SolarWinds Alert with an existing target incident, and invokes downstream systems. A scheduled reconciliation workflow can recover from missed callbacks or unsupported state transitions.
Implementation sequence
Common SolarWinds integration patterns
Pattern 1: Synchronize SolarWinds alerts with ITSM incidents
When to use this pattern
Use this pattern when monitoring alerts must create or update incidents in a service-management platform. It supports callback-style delivery where available and scheduled polling when callback coverage is incomplete.
Integration direction
Example Mapping
| SolarWinds Field | Canonical Field | Target Field |
|---|---|---|
| Alert identifier | externalAlertId | Correlation key |
| Alert severity | priority | Incident priority |
| Node name | affectedResource | Configuration item or description |
| Alert state | lifecycleStatus | Incident state |
Martini implementation pattern
Martini receives an applicable alert action or queries active Alerts and Events, normalizes the payload, applies severity and lifecycle rules, and looks up the target incident by the SolarWinds identifier. It creates, reopens, updates, or resolves the incident without duplication. Transient API failures are retried, while a scheduled reconciliation workflow detects missed callbacks.
Martini capabilities used
- workflows
- API consumption
- API exposure
- data mapping
- business rules
- error handling
Pattern 2: Synchronize SolarWinds Platform inventory
When to use this pattern
Use this pattern when Nodes, Interfaces, and Volumes must be reflected in an asset or configuration system. Stable SolarWinds identifiers should be preferred over display names.
Integration direction
Example Mapping
| SolarWinds Field | Canonical Field | Target Field |
|---|---|---|
| Node ID | sourceId | External asset identifier |
| Node name | resourceName | Asset name |
| Interface status | availabilityStatus | Asset status |
| Volume capacity | capacity | Storage attribute |
Martini implementation pattern
A scheduler-triggered Martini workflow queries each object type with filters and bounded page sizes, joins child objects to parent Nodes, maps the result to the target asset model, and performs idempotent create-or-update operations. Objects absent from a complete synchronization can be marked inactive after validation, while checkpoints and failure details are retained.
Martini capabilities used
- scheduler triggers
- API consumption
- pagination orchestration
- data mapping
- business rules
- checkpointing
Pattern 3: Publish SolarWinds monitoring data to operational reporting
When to use this pattern
Use this pattern when availability, utilization, alert counts, or event trends must be normalized for reporting or analytics. It is appropriate for bounded time windows rather than repeated full extracts.
Integration direction
Example Mapping
| SolarWinds Field | Canonical Field | Target Field |
|---|---|---|
| Node availability | availabilityPercent | Availability metric |
| Interface utilization | utilizationPercent | Interface utilization |
| Volume utilization | storageUtilizationPercent | Storage utilization |
| Event timestamp | observedAt | Event time |
Martini implementation pattern
Martini periodically queries SolarWinds statistics and Events using a bounded window or incremental criterion, converts responses to normalized JSON, enriches them with environment and resource identifiers, and sends them to the reporting target. The workflow stores the last successful window and retries only transient delivery failures to avoid duplicate reporting.
Martini capabilities used
- scheduled workflows
- API consumption
- JSON transformation
- data mapping
- checkpointing
- error handling
Pattern 4: Orchestrate SolarWinds Service Desk incidents and changes
When to use this pattern
Use this pattern when an external application needs to submit or update SolarWinds Service Desk Incidents, Requests, or Changes and receive normalized status updates in return.
Integration direction
Example Mapping
| SolarWinds Field | Canonical Field | Target Field |
|---|---|---|
| External reference | correlationId | Service Desk external reference |
| Request title | summary | Incident or request subject |
| Requested priority | priority | Service Desk priority |
| Workflow status | status | Service Desk state |
Martini implementation pattern
Martini exposes a secured API for normalized commands, validates the request, applies routing and permission rules, and calls the Service Desk REST API. A reverse scheduled workflow retrieves status changes and publishes them to the originating application. Validation failures are returned clearly, while transient API failures use controlled retry and idempotent writes.
Martini capabilities used
- API exposure
- workflows
- authentication and authorization
- validation
- data mapping
- retry handling
Applications commonly integrated with SolarWinds
SolarWinds can be integrated with adjacent operational, service-management, notification, and analytics applications. The exact implementation depends on the SolarWinds product, available alert actions, API permissions, and the target application's API.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Synchronize SolarWinds alerts and events with incidents, configuration items, and operational workflows. | SolarWinds Platform → Martini → ServiceNow | Martini receives applicable alert actions or polls SolarWinds Alerts and Events, correlates them by stable identifiers, maps severity and lifecycle state, and creates or updates ServiceNow incidents with retry and reconciliation handling. |
| Jira Service Management | Create Jira incidents or requests from SolarWinds alerts and synchronize selected resolution or acknowledgment states. | SolarWinds Platform → Martini → Jira Service Management | A Martini workflow consumes SWIS results or configured HTTP alert actions, normalizes alert data, applies deduplication, and calls Jira APIs to create or update issues while recording the external correlation key. |
| Salesforce | Associate infrastructure or service events with customer accounts, cases, or service operations. | SolarWinds Service Desk → Martini → Salesforce | Martini retrieves relevant Service Desk Incidents or SolarWinds monitoring data, maps customer and operational identifiers to Salesforce objects, applies validation rules, and handles rejected or retried writes. |
| Microsoft Teams | Send selected SolarWinds alerts to operational channels and support escalation or acknowledgment workflows. | SolarWinds Platform → Martini → Microsoft Teams | Martini filters alert severity and environment, transforms the alert into a Teams-compatible message through the configured target API or webhook, and logs delivery failures for retry. |
| Slack | Route selected SolarWinds alerts to operational channels and support escalation workflows. | SolarWinds Platform → Martini → Slack | A callback or scheduled SolarWinds workflow applies routing rules, formats alert details for Slack, suppresses duplicates using the SolarWinds alert identifier, and retries transient target failures. |
| PagerDuty | Escalate high-severity SolarWinds alerts to on-call schedules and synchronize acknowledgment or resolution state where supported. | SolarWinds Platform → Martini → PagerDuty | Martini maps SolarWinds severity, node, and alert state to PagerDuty event attributes, preserves the SolarWinds correlation key, and optionally processes return-state updates through a controlled workflow. |
| Splunk | Send SolarWinds events, alerts, and operational summaries to a centralized analytics environment. | SolarWinds Platform → Martini → Splunk | Martini periodically queries bounded SolarWinds time windows, converts Events and alert summaries into normalized JSON, and sends batches to the configured Splunk ingestion endpoint with checkpointing. |
| SolarWinds Service Desk | Convert monitoring alerts into service-management incidents and synchronize monitored asset information with service records. | SolarWinds Platform → Martini → SolarWinds Service Desk | Martini separates the two SolarWinds API surfaces, consumes SWIS data or alert actions, maps Nodes and Alerts to Service Desk Incidents and Assets, and uses idempotent create-or-update operations. |
How to build a SolarWinds integration in Martini
Objective
Identify whether the target is SolarWinds Platform, a specific Orion module, or SolarWinds Service Desk, then configure the correct endpoint and least-privilege credentials.
Instructions in Martini
- Create an environment-specific connection configuration for the selected SolarWinds product
- Store SolarWinds passwords, Windows-backed credentials, or Service Desk API tokens in Martini secrets
- Validate HTTPS/TLS and confirm the integration account permissions
Objective
Select event-style delivery when the required SolarWinds alert coverage is confirmed; otherwise use scheduled polling and reconciliation.
Instructions in Martini
- Configure a secured Martini API or webhook endpoint for applicable SolarWinds alert actions
- Use a scheduler trigger for SWIS or Service Desk polling
- Define the polling interval, bounded query window, and reconciliation schedule
Objective
Receive notifications or retrieve current SolarWinds objects using filtered, paginated, and product-specific API calls.
Instructions in Martini
- Submit SWIS queries for the required Nodes, Interfaces, Volumes, Alerts, or Events
- Call the Service Desk REST API for the selected service-management objects
- Use pagination and incremental criteria where supported
- Retrieve current resource details when an alert callback is incomplete
Objective
Coordinate source retrieval, normalization, business decisions, target writes, and checkpoint persistence in a maintainable Martini workflow.
Instructions in Martini
- Separate SolarWinds Platform and Service Desk API logic
- Route alert, inventory, reporting, and service-management flows independently
- Persist correlation keys and the last successful synchronization point
- Use reusable workflow logic for common authentication, validation, and error handling
Objective
Convert SolarWinds product-specific objects into a canonical model suitable for the target application or reporting destination.
Instructions in Martini
- Map stable SolarWinds identifiers before display names
- Normalize timestamps, severity, lifecycle state, and resource relationships
- Transform monitoring results into JSON or other target formats
- Validate required fields and account for module-specific schema differences
Objective
Implement deduplication, lifecycle, routing, and permission-aware business rules before writing to downstream systems.
Instructions in Martini
- Use alert or object identifiers as correlation keys
- Map active, acknowledged, and resolved alert states to target lifecycle states
- Route only selected severities, environments, or object types
- Prevent a repeated polling observation from creating duplicate incidents
Common SolarWinds data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Nodes | Represent monitored servers, network devices, cloud resources, and other infrastructure endpoints in SolarWinds Platform. | SolarWinds Service Desk, ServiceNow, Device42, Splunk | Martini retrieves Nodes through SWIS, uses stable identifiers for correlation, maps inventory attributes, and creates or updates target assets idempotently. |
| Interfaces | Represent network interfaces and their monitoring data associated with Nodes. | SolarWinds Service Desk, ServiceNow, Device42, reporting platforms | Martini retrieves Interfaces in filtered pages, links them to parent Nodes, transforms utilization and availability fields, and persists a synchronization checkpoint. |
| Volumes | Represent storage volumes or logical disks monitored by SolarWinds Platform. | SolarWinds Service Desk, ServiceNow, data warehouses, reporting platforms | Martini maps volume identifiers, capacity, and utilization data to the target model and applies bounded or incremental synchronization rules. |
| Alerts | Represent configured monitoring alert definitions and alert state information. | ServiceNow, Jira Service Management, PagerDuty, Microsoft Teams, Slack | Martini consumes alert callbacks where configured or polls SWIS, maps severity and lifecycle state, deduplicates by alert identifier, and creates or updates downstream incidents. |
| Events | Represent monitoring events generated by SolarWinds Platform. | ServiceNow, Jira Service Management, Splunk, data warehouses | Martini retrieves Events using bounded time windows or supported incremental criteria, normalizes timestamps and identifiers, and sends them to operational or analytical targets. |
| Incidents | Represent service issues in SolarWinds Service Desk that may originate from SolarWinds alerts or external applications. | ServiceNow, Jira Service Management, Salesforce, custom applications | Martini consumes or creates Service Desk Incidents through the Service Desk REST API, preserves external correlation keys, and maps status, priority, requester, and diagnostic details. |
Authentication and security considerations
Product-specific authentication
SolarWinds Platform commonly uses SolarWinds or Windows/Active Directory-backed accounts with role-based permissions. SolarWinds Service Desk uses an API-token-style credential in request headers. These are separate security models and should be configured independently.
Least privilege and transport security
- Use dedicated integration accounts with only the read and write permissions required by each workflow.
- Use HTTPS/TLS and validate certificates, including internal certificate authorities for self-hosted deployments.
- Store passwords, tokens, and connection settings in Martini secrets or environment configuration rather than source code or mappings.
- Review permissions separately for querying monitoring data, modifying objects, and administrative operations.
Operational considerations for SolarWinds integrations
Query size and synchronization
Use server-side filtering, pagination, bounded time windows, and incremental checkpoints where supported. Avoid broad, frequent queries against production monitoring systems.
Lifecycle and idempotency
Use stable Node, Alert, Event, and Service Desk object identifiers as correlation keys. Map active, acknowledged, and resolved alert states deliberately, and make create-or-update operations idempotent.
Callbacks and reconciliation
Validate which alert types invoke HTTP actions and whether delivery retries are provided. Record failures and run scheduled reconciliation to recover from missed callbacks or unsupported state transitions.
Schema and failure handling
SWIS entities vary with installed modules and platform versions. Test representative payloads, distinguish transient from permanent errors, and review changes to API versions, custom properties, permissions, and target schemas before deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond scripts
Martini provides a maintainable workflow layer for SolarWinds API consumption, alert reception, pagination, transformation, business rules, target writes, and reconciliation instead of scattering logic across scripts and point-to-point integrations.
Reusable integration behavior
Teams can separate SolarWinds Platform and Service Desk concerns, reuse validation and error-handling logic, expose controlled APIs, and keep environment-specific credentials outside workflow implementation.
Operational reliability
- Coordinate scheduled, event-style, and API-triggered processing.
- Apply idempotency and correlation rules before creating downstream incidents or assets.
- Handle retries, checkpoints, logging, and reconciliation in one integration design.
- Adapt mappings as SolarWinds modules, versions, and target schemas change.
Frequently asked questions
SolarWinds Platform can be integrated through the SWIS REST/JSON API, Orion SDK interfaces, scheduled polling, and configured alert actions or HTTP callbacks where supported. SolarWinds Service Desk uses a separate REST API for service-management objects. SOAP may be relevant for legacy Orion environments, while direct database access is deployment-dependent and should not be assumed for writes.
Yes. Martini can consume the SolarWinds Platform SWIS REST API and SolarWinds Service Desk REST API, receive applicable SolarWinds alert actions, schedule synchronization workflows, map product-specific objects, and expose APIs for normalized commands or events. No native Martini SolarWinds connector is documented in the supplied context.
No. A dedicated SolarWinds connector is not required. Martini can integrate using SolarWinds' confirmed native mechanisms, including SWIS REST/JSON, the Service Desk REST API, configured HTTP alert actions, and a documented legacy SOAP interface where necessary.
Lonti does not charge an additional per-connector or per-vendor fee to integrate SolarWinds. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from SolarWinds, cloud infrastructure, or other third-party systems based on licensing, API usage, hosting, and deployment model.
Use SWIS REST/JSON for SolarWinds Platform integrations and the separate REST API for SolarWinds Service Desk when those interfaces support the required operations. Use alert actions for selected event-driven scenarios after validating coverage. SOAP should generally be limited to compatibility requirements, and GraphQL was not confirmed for the reviewed SolarWinds scope.
SolarWinds Platform alert actions can provide HTTP-style callback behavior for configured alerts in applicable deployments, but this is not universal webhook coverage for every SolarWinds object or state transition. Polling and reconciliation may be required for complete lifecycle synchronization.
Martini can use scheduled workflows to query SWIS or the Service Desk REST API, process paginated results, map objects, and write them to target applications. Incremental criteria, bounded time windows, stable identifiers, checkpoints, and reconciliation workflows help control load and recover from missed callbacks.
Martini maps SolarWinds objects to canonical and target models, validates required fields, applies lifecycle and routing rules, and uses stable SolarWinds identifiers for idempotency. Workflows can distinguish authentication, permission, query, network, throttling, and target validation failures, retry transient errors, and log failures for reconciliation.
Related Martini documentation
APIs
Data
Connect SolarWinds to your enterprise workflows
Use Martini to turn SolarWinds monitoring and Service Desk APIs into reliable, governed integrations with the applications and operational processes your organization depends on.