.png)
SysAid Integration Guide
Integrate SysAid service-management data with enterprise applications through its REST API, scheduled workflows, and tenant-specific webhook or callback capabilities.
SysAid integration options at a glance
SysAid’s primary documented integration mechanism is its REST API, which supports operations involving Service Records, Users, Companies, Assets, Problems, and Changes. Martini can consume these APIs through workflows, apply validation and business rules, transform responses into a shared enterprise model, and synchronize results with downstream applications. SysAid may provide outbound webhook or HTTP callback capabilities for selected modules and events, but broad coverage is not confirmed and must be validated in the target tenant. Scheduled REST polling is therefore an important fallback. API keys or token-based credentials should be stored in Martini environment secrets, while large transfers should use pagination, checkpoints, throttling, and restart-safe processing.
| Integration point | Supported by SysAid? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Create, read, update, and search Service Records, Users, Companies, Assets, Problems, and Changes. REST access is SysAid’s primary documented integration mechanism. | Martini can consume the SysAid REST API from workflows, map responses, apply business rules, and expose a controlled API façade for other systems. |
| Authentication | Yes | SysAid documents REST API authentication using credentials or an API key or token associated with the SysAid environment. | Martini can store credentials in environment secrets and apply them to API-consuming workflows without embedding them in workflow logic. |
| Webhooks / outbound callbacks | Not confirmed | Selected SysAid modules or configurations may provide outbound notifications, but broad object and event coverage was not confirmed. | Where the tenant exposes a suitable callback, Martini can expose an authenticated endpoint and process the notification; otherwise scheduled polling can be used. |
| File / attachment APIs | Limited | Service Records and other service-management objects may contain attachments, but generally available attachment endpoints and operations require tenant-level validation. | Martini can orchestrate attachment metadata and binary transfers when the target SysAid API definition confirms the required operations and permissions. |
| Bulk / async / batch APIs | Not confirmed | A separate SysAid bulk or asynchronous API was not confirmed. Large transfers should use paginated REST processing unless the tenant documents another endpoint. | Martini can implement pagination, checkpoints, throttling, bounded retries, and restart-safe workflow execution. |
| Scheduled synchronization | Yes | Scheduled polling is a practical fallback when the required SysAid webhook or callback is unavailable, using timestamps or other supported filters for incremental retrieval. | Martini scheduler-triggered workflows can retrieve changed objects, checkpoint successful pages, and synchronize downstream systems. |
| GraphQL APIs | Not confirmed | No official SysAid GraphQL API documentation was confirmed in the reviewed sources. | Martini supports GraphQL consumption generally, but a SysAid GraphQL integration should not be assumed without tenant documentation. |
| SOAP APIs | Not confirmed | A current SysAid SOAP integration method was not confirmed; older deployments may differ and require tenant-specific verification. | Martini can consume SOAP services generally, but SOAP should not be selected for SysAid without confirmed endpoint documentation. |
How SysAid exposes data and business events
SysAid REST APIs
SysAid documents REST APIs as the primary way to work with service-management resources. The API can support operations for Service Records, Users, Companies, Assets, Problems, and Changes, subject to the edition, modules, permissions, and API definition of the target tenant.
Martini implementation pattern
Martini uses an API-consuming workflow to authenticate, retrieve or submit SysAid resources, normalize the response, apply business rules, and write to one or more target systems. Pagination, incremental filters, checkpointing, and bounded retries support reliable synchronization.
Implementation sequence
Scheduled REST synchronization
Because broad SysAid webhook coverage was not confirmed, scheduled polling is an important integration pattern. A workflow can retrieve objects changed since a stored timestamp or other supported filter.
Martini implementation pattern
Martini starts a scheduled workflow, requests pages in order, and stores a checkpoint only after successful processing. An overlap window, throttling, and restart-safe handling reduce the risk of missed or duplicated changes.
Implementation sequence
SysAid webhook or callback notifications
SysAid may provide outbound webhook-style automation or HTTP callbacks for selected modules and configurations, but coverage for every object and event is not confirmed.
Martini implementation pattern
When the target tenant exposes the required event, Martini exposes an authenticated endpoint, validates the notification, and retrieves the current SysAid resource before transforming it. If no callback is available, the same workflow can be invoked by scheduled polling.
Implementation sequence
SysAid attachment handling
SysAid service-management objects may contain attachments, but the available attachment endpoints, operations, content limits, and permissions require validation in the target tenant.
Martini implementation pattern
Martini can separate object metadata from binary content, call confirmed attachment operations, and transfer files only when the tenant API supports the required action. Checksums or source attachment identifiers can help prevent duplicates.
Implementation sequence
Common SysAid integration patterns
Pattern 1: Synchronize Service Records with a CRM
When to use this pattern
Use this pattern when customer-facing teams need SysAid ticket status, requester context, or resolution information in Salesforce or another customer-management application. It supports scheduled synchronization and optional reverse updates where ownership rules are explicit.
Integration direction
Example Mapping
| SysAid Field | Canonical Field | Target Field |
|---|---|---|
| Service Record ID | sourceTicketId | External Ticket ID |
| Title | subject | Case Subject |
| Status | lifecycleStatus | Case Status |
| Priority | severity | Case Priority |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Service Records using supported incremental filters, enriches them with Users and Companies when needed, maps status and priority values, and upserts Salesforce cases. It stores source identifiers, uses an overlap window, prevents feedback loops, and sends transient failures through bounded retry handling.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Enrich Service Records with Users and Companies
When to use this pattern
Use this pattern when downstream routing requires normalized requester, department, organizational, or ownership data that is related to a SysAid Service Record rather than fully present in the initial payload.
Integration direction
Example Mapping
| SysAid Field | Canonical Field | Target Field |
|---|---|---|
| User ID | requesterId | Requester Identifier |
| Company ID | organizationId | Owning Organization |
| Department | requesterDepartment | Department |
| Service Record ID | sourceTicketId | Correlation ID |
Martini implementation pattern
Martini retrieves the Service Record and related Users and Companies, validates relationship availability, applies department and escalation rules, and sends a normalized payload to the target API. Missing relationships are treated as validation exceptions rather than silently creating incomplete data.
Martini capabilities used
- workflow orchestration
- REST API consumption
- data mapping
- validation
- business rules
- error handling
Pattern 3: Synchronize Assets with an operational platform
When to use this pattern
Use this pattern when asset ownership, configuration, procurement, or finance processes need a controlled copy of SysAid Assets. It is suited to scheduled, incremental processing rather than an assumed bulk API.
Integration direction
Example Mapping
| SysAid Field | Canonical Field | Target Field |
|---|---|---|
| Asset ID | sourceAssetId | External Asset ID |
| Asset Name | assetName | Configuration Item Name |
| Asset Type | assetCategory | Class |
| Assigned User | assignedUserId | Assigned To |
Martini implementation pattern
A scheduled workflow reads paginated Assets, transforms tenant-specific fields and categories, and upserts them into the target platform. Martini commits checkpoints only after successful writes, throttles requests, and routes invalid or conflicting assets for review.
Martini capabilities used
- scheduled workflows
- pagination orchestration
- data transformation
- upsert logic
- checkpointing
- retry handling
Pattern 4: Route selected SysAid events to incident collaboration tools
When to use this pattern
Use this pattern for high-priority Service Records, escalations, or Changes that require operational notifications. Use a SysAid callback only when the tenant confirms the required event; otherwise poll for recently changed objects.
Integration direction
Example Mapping
| SysAid Field | Canonical Field | Target Field |
|---|---|---|
| Priority | severity | Notification Severity |
| Title | summary | Message Title |
| Status | lifecycleStatus | Message Status |
| Service Record ID | sourceTicketId | Correlation Reference |
Martini implementation pattern
Martini receives and validates a confirmed callback or retrieves recent changes, filters events by priority and assignment rules, maps the notification payload, and publishes it to the collaboration endpoint. Duplicate notifications are suppressed using source identifiers and retryable delivery failures are isolated.
Martini capabilities used
- API endpoints
- workflow triggers
- event filtering
- data mapping
- business rules
- error handling
Applications commonly integrated with SysAid
SysAid can be integrated with adjacent enterprise applications through its REST API and, where available, tenant-specific outbound notifications. These are representative architecture patterns rather than claims of native SysAid connectors.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer context, contacts, account ownership, and support cases with SysAid Service Records and Companies. | Salesforce → Martini → SysAid | Use Salesforce events or scheduled retrieval to create or update SysAid Service Records, then retrieve SysAid status and resolution changes and map them back to Salesforce. Persist cross-system identifiers and apply loop-prevention rules. |
| ServiceNow | Coordinate selected tickets, users, and configuration data when organizations operate both service-management platforms during coexistence or consolidation. | SysAid → Martini → ServiceNow | Poll or receive eligible SysAid changes, normalize ticket and user fields, and upsert selected Service Records into ServiceNow. Use source identifiers, ownership rules, and conflict handling to prevent synchronization loops. |
| Jira | Link SysAid incidents, Problems, or Changes with software-development work and return engineering status to service operations. | SysAid → Martini → Jira | Route qualifying SysAid Service Records or Problems to Jira through an API workflow, map priority and ownership fields, and write Jira status or resolution updates back only when business rules permit. |
| Microsoft Entra ID | Use identity, department, group, and account-status information to normalize SysAid Users and requester data. | Microsoft Entra ID → Martini → SysAid | Retrieve approved identity attributes, map them to SysAid Users, validate required values, and apply controlled update rules while preserving SysAid identifiers and permission boundaries. |
| Slack | Notify operational channels about high-priority Service Records, escalations, and Changes. | SysAid → Martini → Slack | Receive an eligible SysAid callback when available or poll for recently changed records, apply priority and assignment rules, and publish a concise normalized notification with a correlation link or identifier. |
| PagerDuty | Escalate selected high-priority SysAid incidents or operational alerts to an incident-response workflow. | SysAid → Martini → PagerDuty | Filter SysAid Service Records by priority and assignment criteria, transform them into PagerDuty event data, and process status feedback only where the target workflow and tenant permissions support it. |
How to build a SysAid integration in Martini
Objective
Establish access to the target SysAid environment using its documented REST authentication method and the minimum permissions needed for the selected objects.
Instructions in Martini
- Confirm the tenant API base URL, available resources, permissions, and authentication method
- Store the API key or token in Martini environment secrets
- Configure request authentication without embedding credentials in workflow logic
- Validate access with a low-risk read operation
Objective
Select the trigger that matches the tenant’s confirmed capabilities and the required freshness of the integration.
Instructions in Martini
- Use a scheduled workflow for reliable incremental polling
- Use a Martini endpoint only when SysAid provides the required outbound callback
- Define the object and event scope explicitly
- Set a checkpoint or correlation strategy before processing data
Objective
Retrieve current SysAid resources efficiently and safely, including related Users or Companies when enrichment is required.
Instructions in Martini
- Use supported filters, pagination, and sort order
- Retrieve related objects only when required by business rules
- Apply throttling and bounded concurrency
- Preserve source identifiers and response context
Objective
Coordinate SysAid calls, enrichment, validation, target writes, and exception paths in a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, and delivery stages
- Branch for validation, not-found, conflict, rate-limit, and server errors
- Use reusable workflow logic for common resource handling
- Keep checkpoint commits after successful downstream processing
Objective
Convert tenant-specific SysAid fields and enumerations into a stable enterprise model and target-system format.
Instructions in Martini
- Map Service Records, Users, Companies, Assets, Problems, or Changes explicitly
- Normalize dates, priorities, statuses, and identifiers
- Treat custom fields and enumerations as tenant configuration
- Validate required target fields before submission
Objective
Enforce ownership, routing, idempotency, privacy, and loop-prevention policies before writing data.
Instructions in Martini
- Use SysAid identifiers as external keys
- Check for an existing target object before non-idempotent creates
- Filter records by priority, assignment, module, or status as required
- Prevent reverse-sync feedback loops with source metadata and timestamps
Common SysAid data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Service Records | Synchronize incidents, service requests, priorities, assignments, status, and resolution information. | Salesforce, ServiceNow, Jira, Slack, PagerDuty | Martini retrieves or receives eligible changes, validates required fields, maps the Service Record model, and upserts using the SysAid identifier. |
| Users | Normalize employees, requesters, agents, departments, and ownership information. | Microsoft Entra ID, Salesforce, ServiceNow | Martini retrieves related Users, applies field and permission rules, and enriches Service Records or synchronizes approved user attributes. |
| Assets | Synchronize hardware, software, and configuration items with operational, procurement, or finance systems. | ServiceNow, procurement platforms, finance applications | Martini processes paginated Assets, preserves asset identifiers, transforms attributes, and writes checkpointed upserts. |
| Companies | Associate users and Service Records with organizations or customer companies. | Salesforce, ServiceNow, customer-management applications | Martini resolves company relationships, normalizes names and identifiers, and applies ownership and duplicate-prevention rules. |
| Problems | Share root-cause records and corrective-action information with engineering or service-management systems. | Jira, ServiceNow, collaboration platforms | Martini filters eligible Problems, maps lifecycle and ownership fields, and handles conflicts or retries through workflow error paths. |
| Changes | Coordinate change-management records, approvals, implementation details, and operational notifications. | ServiceNow, Jira, Slack, Microsoft Teams | Martini validates change status and approval data, routes selected Changes, and records source identifiers for idempotent updates. |
Authentication and security considerations
Authentication and access control
SysAid REST authentication commonly uses an API key or token-based mechanism associated with the target environment. The exact header and provisioning process can vary by product version and tenant configuration.
- Store SysAid credentials in Martini environment secrets.
- Use a dedicated SysAid integration account with minimum required permissions.
- Restrict access to the Service Records, Users, Companies, Assets, Problems, or Changes required by each workflow.
- Protect inbound Martini callback endpoints with authentication and authorization when callbacks are confirmed.
- Review personal data in Users, Service Records, and attachments before forwarding it to other systems.
Operational considerations for SysAid integrations
Reliable synchronization
SysAid rate limits and tenant quotas were not confirmed. Configure throttling, bounded concurrency, and retry delays, and treat appropriate 429 and transient 5xx responses as retryable.
Pagination and checkpoints
Confirm page size, ordering, and filters for each endpoint. Use incremental synchronization with a small overlap window and commit checkpoints only after downstream writes succeed.
Data integrity
- Use SysAid identifiers as external keys and prevent duplicate creates.
- Separate authentication, validation, not-found, conflict, rate-limit, and server errors.
- Treat custom fields, statuses, categories, priorities, and assignment values as tenant configuration.
- Validate attachment endpoints, content limits, and permissions before transferring binary content.
- Store failed records in a controlled retry or dead-letter workflow and avoid logging credentials or sensitive requester information.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration logic
Scripts and point-to-point connections can duplicate authentication, mapping, retry, and monitoring logic across each interface. Martini centralizes these concerns in workflows and reusable integration assets.
- Consume SysAid REST APIs and expose controlled APIs without coupling every target directly to SysAid.
- Apply consistent mappings, validation, routing, idempotency, and business rules.
- Support scheduled, callback-driven, and restart-safe synchronization patterns.
- Separate secrets and environment configuration from implementation logic.
- Provide structured error paths and operational visibility for troubleshooting and replay.
Frequently asked questions
SysAid’s primary documented integration mechanism is its REST API. Enterprise workflows can create, read, update, and search Service Records, Users, Companies, Assets, Problems, and Changes. Scheduled polling is appropriate when real-time callbacks are unavailable; tenant-specific webhook or callback capabilities must be confirmed before relying on them.
Yes. Martini can integrate with SysAid by consuming its REST API, orchestrating related resource calls, mapping and transforming data, and exposing APIs for downstream applications. If the target tenant provides a suitable outbound webhook or callback, Martini can receive and process it; otherwise scheduled REST synchronization can be used.
No dedicated SysAid connector is required. Martini can use SysAid’s confirmed native REST API and authentication mechanisms, plus a tenant-specific webhook or callback if one is available for the required event.
Lonti does not charge an additional per-connector or per-vendor fee to integrate SysAid. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from SysAid, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use the SysAid REST API for current integrations. Scheduled, paginated REST workflows are the dependable fallback when event coverage is unavailable. Webhooks or callbacks should be used only after confirming that the tenant supports the required object and event. GraphQL and a current SOAP method were not confirmed.
Possibly, but only for events exposed by the target tenant and enabled SysAid configuration. Broad webhook coverage for Service Records, Assets, Users, Problems, and Changes was not confirmed. Martini can receive a confirmed callback; scheduled REST polling is the fallback.
Martini workflows retrieve or receive SysAid objects, optionally enrich them with related Users or Companies, validate tenant-specific fields, and map them to a canonical or target-system model. Incremental filters, pagination, checkpoints, source identifiers, and overlap windows support reliable synchronization.
Martini can distinguish authentication, validation, not-found, conflict, rate-limit, and server failures, retry appropriate transient responses with bounded delays, and route unrecoverable records for replay. Persisting SysAid identifiers and correlation metadata supports idempotent upserts and duplicate prevention.
Related Martini documentation
Mapping
Plan your SysAid integration with Martini
Use SysAid’s REST API, confirmed tenant callbacks, and Martini workflows to build secure, maintainable synchronization and automation across your enterprise systems.