.png)
Jira Service Management Integration Guide
Connect Jira Service Management service requests, issues, comments, attachments, and events with enterprise applications through REST APIs, webhooks, and scheduled workflows.
Jira Service Management integration options at a glance
Jira Service Management provides REST APIs for service requests, issues, service projects, customers, organizations, comments, queues, request types, SLAs, and attachments. Jira Cloud also supports configurable webhooks for selected issue and comment events, while bulk and asynchronous operations are available for selected issue activities. OAuth 2.0 and API-token-based Basic Authentication support delegated and server-to-server access. Martini can consume these APIs, receive supported webhook notifications, orchestrate scheduled reconciliation, paginate through results, map Jira JSON payloads, and expose normalized APIs for downstream applications.
| Integration point | Supported by Jira Service Management? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Create and retrieve service requests, search and update issues, add public comments or internal notes, transition requests, retrieve request types, queues, customers, organizations, and SLA information. | Martini can consume Jira Service Management and Jira platform REST APIs, generate reusable API-oriented integration assets, map JSON responses, and orchestrate calls in workflows. |
| Webhooks / outbound callbacks | Limited | Receive selected Jira events such as issue creation and updates, comments, worklogs, and other configured platform events. Coverage does not guarantee notification for every JSM-specific state change. | Martini can expose an endpoint or consume webhook input through a workflow, validate and normalize the event, retrieve the current Jira resource, and combine event processing with scheduled reconciliation. |
| Bulk / async / batch APIs | Limited | Process multiple Jira issues or selected issue-related activities while reducing individual API calls. Individual JSM REST operations remain necessary for many service-management actions. | Martini can invoke supported bulk operations, track asynchronous responses where applicable, and fall back to controlled individual requests with retry and checkpoint logic. |
| File / attachment APIs | Yes | Retrieve attachment metadata, download files, and upload attachments to Jira issues subject to permissions, headers, file-size limits, and content policies. | Martini can separate attachment metadata from content processing, transfer files between APIs or storage systems, validate content, and correlate attachments with the originating issue. |
| Authentication | Yes | Use OAuth 2.0 for delegated authorization or API-token-based Basic Authentication for controlled server-to-server access. Effective access also depends on scopes and Jira permissions. | Martini can store tokens and credentials in secrets or environment configuration and apply the selected authentication method to outbound API requests. |
| Scheduled synchronization | Yes | Use JQL searches, updated timestamps, issue IDs, and checkpoints for incremental synchronization and reconciliation when webhook coverage is incomplete or events are missed. | Martini can schedule workflows, paginate through results, persist checkpoints, apply idempotent upserts, and replay failed work without creating duplicate requests. |
| SDKs and client libraries | Limited | Atlassian tooling and community or language-specific libraries can support development, but direct REST calls are generally more controllable for tracing, retries, pagination, and API-version management. | Martini does not require an Atlassian SDK; it can consume the documented REST endpoints directly and add custom logic where project-specific behavior requires it. |
| Database access | No | Direct database access is not an appropriate or supported integration pattern for Jira Cloud tenant data. | Martini should use Jira REST APIs, webhooks, and supported Atlassian services rather than attempting direct database connectivity. |
How Jira Service Management exposes data and business events
Jira Service Management REST APIs
Jira Service Management exposes REST resources for service requests, service desks, customers, organizations, queues, request types, SLA information, and related operations. Jira platform REST APIs extend this model with issues, comments, transitions, users, projects, and attachments.
Martini implementation pattern
Martini implementation pattern: A workflow authenticates to the relevant Jira Cloud API, retrieves or submits the required resource, validates the response, maps Jira JSON to a canonical model, and writes the result to the target application. Project-specific request types, fields, permissions, and transitions remain configurable.
Implementation sequence
Jira Cloud Webhooks
Jira Cloud supports configurable webhooks for selected events, including issue creation and updates, comments, worklogs, and other platform events. Webhook coverage is event-specific and does not represent every JSM-specific state change.
Martini implementation pattern
Martini implementation pattern: Martini receives the webhook notification through an endpoint or workflow trigger, validates the event, retrieves the current Jira resource rather than relying only on the notification payload, and processes the change idempotently. A scheduled reconciliation workflow covers missed or unsupported events.
Implementation sequence
Bulk and asynchronous operations
Jira Cloud provides bulk and asynchronous operations for selected issue-related activities. These operations can reduce individual calls but do not replace the full JSM REST API for service-management workflows.
Martini implementation pattern
Martini implementation pattern: A workflow groups eligible issue actions, invokes a supported bulk or asynchronous endpoint, records the operation identifier where applicable, and polls or processes the result. Unsupported or failed actions are routed to controlled individual requests or a retry queue.
Implementation sequence
Jira Attachment APIs
Jira issue attachment endpoints support attachment metadata and file operations subject to project permissions, issue permissions, request headers, size limits, and content policies.
Martini implementation pattern
Martini implementation pattern: Martini retrieves attachment metadata, authenticates file access, transfers content through a workflow, and links the target file to the corresponding issue or service request. File validation, duplicate detection, and security scanning rules can be applied before delivery.
Implementation sequence
Scheduled JQL reconciliation
Jira integrations can use JQL searches, updated timestamps, issue keys or IDs, and checkpoints for incremental synchronization. Scheduled reconciliation is important because webhook coverage is selected and event delivery can overlap or be missed.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow queries Jira for changes after a stored checkpoint, paginates through results, retrieves related JSM data, and performs idempotent upserts. The workflow advances the checkpoint only after the relevant target writes succeed.
Implementation sequence
Common Jira Service Management integration patterns
Pattern 1: Synchronize service requests with Salesforce cases
When to use this pattern
Use this pattern when customer-support teams need Salesforce case context and Jira Service Management service-request processing to remain aligned. The flow can begin with a JSM event or Salesforce case change and should define which system owns customer, status, and resolution fields.
Integration direction
Example Mapping
| Jira Service Management Field | Canonical Field | Target Field |
|---|---|---|
| issue.key | sourceRequestId | Jira_Request_Key__c |
| requestType.name | requestCategory | Case_Type__c |
| priority.name | priority | Priority |
| reporter.emailAddress | customerEmail | ContactEmail__c |
Martini implementation pattern
Martini receives selected Jira events or polls for updated service requests, retrieves the complete request and customer context, maps the payload to a Salesforce Case, and stores both identifiers. For reverse updates, it validates the Salesforce change, applies an explicit status and comment mapping, and calls the appropriate JSM operation. Correlation keys, loop-prevention rules, retries, and a reconciliation workflow handle duplicates and missed events.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- scheduled synchronization
- error handling
Pattern 2: Route high-priority incidents to Slack and Microsoft Teams
When to use this pattern
Use this pattern when support, engineering, or leadership teams need focused notifications for incidents and escalations without receiving every JSM change. Routing should consider service project, priority, component, status, and assignment.
Integration direction
Example Mapping
| Jira Service Management Field | Canonical Field | Target Field |
|---|---|---|
| issue.key | incidentId | Message title |
| priority.name | severity | Notification severity |
| summary | incidentSummary | Message body |
| assignee.displayName | owner | Message owner |
Martini implementation pattern
Martini receives a selected Jira webhook or discovers changes through scheduled polling, retrieves the current issue, evaluates notification rules, and posts a normalized message through the destination HTTP API. The workflow records the last notified event and suppresses duplicate notifications while retrying transient destination or Atlassian failures.
Martini capabilities used
- webhook consumption
- workflows
- conditional routing
- data transformation
- API consumption
- retry handling
Pattern 3: Coordinate incidents and changes with ServiceNow
When to use this pattern
Use this pattern when different teams operate JSM and ServiceNow or when an organization is migrating between ITSM platforms. The design must assign ownership by object and avoid assuming that Jira status names or transition IDs are universal.
Integration direction
Example Mapping
| Jira Service Management Field | Canonical Field | Target Field |
|---|---|---|
| issue.key | externalTicketId | Correlation ID |
| issue.issueType.name | workItemType | Record type |
| status.name | lifecycleState | State |
| comment.body | conversationEntry | Additional comments |
Martini implementation pattern
Martini orchestrates bidirectional API calls, translates incidents, changes, approvals, comments, priorities, and state transitions, and applies system-of-record rules before writing each side. Project-specific Jira transition mappings are retrieved or configured, and permission, validation, rate-limit, and duplicate errors are separated for retry or operational review.
Martini capabilities used
- workflow orchestration
- API consumption
- data mapping
- business rules
- correlation management
- error handling
Pattern 4: Reconcile JSM issues on a schedule
When to use this pattern
Use this pattern when webhook coverage is incomplete, event delivery is not sufficient for audit requirements, or a downstream database and application require reliable incremental synchronization.
Integration direction
Example Mapping
| Jira Service Management Field | Canonical Field | Target Field |
|---|---|---|
| id | sourceObjectId | jira_issue_id |
| updated | lastChangedAt | updated_at |
| project.key | serviceProjectKey | service_project |
| status.name | lifecycleState | status |
Martini implementation pattern
A scheduled Martini workflow runs a bounded JQL search using a stored timestamp or issue checkpoint, follows pagination, retrieves required request-specific data, and upserts the target database. It advances the checkpoint only after successful writes, uses stable Jira IDs for idempotency, and records failed items for replay.
Martini capabilities used
- scheduler triggers
- workflows
- REST API consumption
- pagination logic
- data mapping
- idempotent processing
- monitoring
Applications commonly integrated with Jira Service Management
Jira Service Management can be connected with customer-support, collaboration, incident-response, knowledge, and development applications. Martini can coordinate these flows through REST APIs, selected Jira webhook events, scheduled reconciliation, field mapping, business rules, and durable error handling.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer cases, account context, contacts, and support interactions with Jira Service Management service requests. | Salesforce → Martini → Jira Service Management | Use Salesforce API events or polling and Jira REST APIs to create or update service requests. Store the Salesforce case ID and Jira issue or request ID as correlation keys, then synchronize status, comments, and resolution fields with idempotent upserts. |
| ServiceNow | Coordinate incidents, changes, approvals, and service operations across two ITSM platforms during migrations, mergers, or shared-operating-model scenarios. | ServiceNow → Martini → Jira Service Management | Map incidents, changes, comments, priorities, and state transitions between the systems. Apply system-of-record rules per object, retrieve project-specific Jira transitions, and route validation, permission, and rate-limit failures for retry or review. |
| Slack | Notify support and engineering teams about incidents, escalations, assignments, and status changes without requiring every stakeholder to use the JSM interface. | Jira Service Management → Martini → Slack | Receive selected Jira webhook events or poll for changes, retrieve the current issue through the REST API, filter by project and priority, and publish a normalized notification through Slack's HTTP API. Deduplicate events using the Jira issue key and update timestamp. |
| Microsoft Teams | Distribute incident and request notifications to Teams channels and support operational collaboration. | Jira Service Management → Martini → Microsoft Teams | Use a Martini workflow to receive or retrieve JSM changes, apply routing rules by service project, priority, or status, and send structured messages to Teams. Optional action handling can call back into Jira REST APIs after validating permissions and transitions. |
| PagerDuty | Escalate high-priority JSM incidents to on-call responders and return acknowledgment or resolution state to the service request. | Jira Service Management → Martini → PagerDuty | Trigger on selected Jira events or a scheduled priority search, create or update the PagerDuty incident, persist the cross-system identifier, and write acknowledgment or resolution details back to the Jira issue while preventing duplicate incident creation. |
| Opsgenie | Connect JSM incidents with alerting, on-call schedules, and escalation policies in an Atlassian-aligned operational environment. | Jira Service Management → Martini → Opsgenie | Route qualifying JSM incidents to Opsgenie through its API, correlate the alert and Jira issue identifiers, and synchronize acknowledgment and resolution updates. Verify product-specific payloads and permissions before production deployment. |
| Confluence | Link service requests and incidents to knowledge articles, runbooks, and post-incident documentation. | Jira Service Management → Martini → Confluence | Extract request, incident, and project context from JSM, resolve approved Confluence pages or knowledge references, and write links or documentation metadata back to the issue. Use business rules to restrict sensitive incident content. |
| Jira Software | Coordinate JSM incidents and service requests with engineering bugs, tasks, and development work. | Jira Service Management → Martini → Jira Software | Classify JSM issues that require engineering work, create or update linked Jira Software issues, and synchronize selected status, priority, comments, and resolution fields. Correlation keys and transition maps prevent loops and duplicate work items. |
How to build a Jira Service Management integration in Martini
Objective
Establish secure access to Jira Service Management and the required target systems.
Instructions in Martini
- Choose OAuth 2.0 for delegated authorization or API-token-based Basic Authentication for a controlled service account.
- Store tokens, credentials, site URLs, and environment-specific settings in Martini secrets or secure configuration.
- Confirm Jira scopes, project access, service-project roles, and permissions for requests, comments, transitions, customers, and attachments.
Objective
Select an event-driven, API-led, or scheduled entry point based on the required completeness and latency.
Instructions in Martini
- Receive selected Jira webhook events through a Martini endpoint or workflow trigger.
- Use a scheduled workflow with JQL and updated timestamps when webhook coverage is incomplete.
- Define a reconciliation interval and checkpoint strategy for missed or delayed events.
Objective
Obtain the complete Jira object needed for reliable processing rather than depending only on a notification payload.
Instructions in Martini
- Call the relevant JSM or Jira platform REST endpoint for the issue, service request, comments, fields, or attachments.
- Follow pagination for searches, customers, comments, and other paginated resources.
- Retrieve request-type and transition metadata when project-specific configuration affects the operation.
Objective
Coordinate the end-to-end workflow across Jira Service Management and the target application.
Instructions in Martini
- Route the workflow by service project, request type, issue type, priority, status, or event type.
- Persist Jira issue IDs, keys, request IDs, external IDs, and checkpoints for correlation.
- Separate synchronous updates from asynchronous or queued work when rate limits or file processing require controlled throughput.
Objective
Transform Jira's issue-oriented and service-specific model into the canonical target model.
Instructions in Martini
- Map request type, issue type, status, priority, reporter, customer, organization, SLA, comments, custom fields, and attachments explicitly.
- Preserve the distinction between public comments and internal notes.
- Normalize timestamps, identifiers, enumerations, and missing values before writing to the target.
Objective
Enforce business ownership, validation, visibility, and duplicate-prevention rules.
Instructions in Martini
- Validate required fields against the selected service project and request type.
- Use stable correlation keys and upsert logic to prevent duplicate cases, incidents, or notifications.
- Apply system-of-record and transition rules instead of assuming that all Jira projects share the same workflow.
Common Jira Service Management data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Service requests | Customer-facing requests submitted through a portal, email channel, API, or configured channel. | Salesforce, ServiceNow, Slack, Microsoft Teams, reporting databases | Martini retrieves or receives request changes, maps request type, customer, status, priority, comments, and identifiers, and performs idempotent create or update operations. |
| Issues | Jira work items underlying incidents, service requests, problems, changes, and other work types. | ServiceNow, Jira Software, PagerDuty, Opsgenie, data warehouses | Martini uses issue IDs and keys for correlation, retrieves current fields through REST APIs, applies transition and routing rules, and stores checkpoints. |
| Request types | Definitions controlling customer-facing forms, issue types, fields, workflows, and portal presentation. | Service catalogs, intake applications, integration configuration stores | Martini can retrieve request-type metadata to validate payloads and select the correct field and transition mapping per service project. |
| Customers | Individuals or portal users who submit or participate in service requests. | Salesforce, identity platforms, customer directories | Martini maps customer identifiers and contact attributes, respects visibility rules, and avoids treating customer access as equivalent to agent access. |
| Comments | Public replies or internal notes associated with a service request or issue. | Salesforce, ServiceNow, Slack, Microsoft Teams | Martini preserves the distinction between customer-visible comments and internal notes and routes each type according to target-system visibility rules. |
| Attachments | Files associated with issues or service requests, such as screenshots, logs, and evidence. | File stores, case-management systems, collaboration platforms | Martini transfers metadata and content separately, applies file-size and content rules, detects duplicates, and maintains issue correlation. |
Authentication and security considerations
Authentication options
Jira Cloud supports OAuth 2.0 for delegated authorization and API-token-based Basic Authentication for controlled server-to-server integrations. Martini can apply the selected method when consuming Jira APIs.
Permissions and scopes
Authentication does not guarantee access to every service request. OAuth scopes, Jira project permissions, service-project roles, issue security, customer visibility, and agent access all affect the result.
Secret handling
- Store API tokens, OAuth configuration, and site-specific credentials in Martini secrets or secure environment configuration.
- Limit service accounts to the projects and operations required by the integration.
- Do not expose tokens in workflow payloads, logs, or error messages.
Operational considerations for Jira Service Management integrations
Rate limits and pagination
Atlassian may return HTTP 429 responses, and Jira REST resources are commonly paginated. Use bounded concurrency, response metadata, Retry-After when supplied, exponential backoff, and maximum retry counts.
Idempotency and reconciliation
Webhook retries and scheduled searches can overlap. Store Jira IDs, issue keys, request IDs, external identifiers, and checkpoints, and use upsert logic. Combine selected webhooks with periodic JQL-based reconciliation.
Project-specific workflows
Request types, required fields, statuses, and transition IDs can differ between service projects. Retrieve or configure mappings per project instead of hard-coding a universal transition model.
Attachments and schema changes
Handle attachment metadata and content separately, enforce file-size and content policies, and detect duplicate files. Keep mappings configurable to accommodate Atlassian API changes, permissions, deprecations, and new required fields.
Testing and monitoring
Test public comments, internal notes, permissions, transitions, pagination, rate limits, and duplicate delivery in a representative project. Log the site, project, issue key, endpoint, response status, and correlation ID without exposing credentials or sensitive customer data.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than an API call
Point-to-point scripts often combine authentication, pagination, mapping, retry logic, and business rules in code that is difficult to govern. Martini provides workflows for coordinating Jira Service Management with applications, databases, files, and messaging systems.
Centralize transformation and policy
Martini can map Jira's issue-oriented model into canonical models, preserve public-versus-internal comment semantics, apply project-specific transition rules, and expose controlled APIs for downstream consumers.
Improve reliability and maintainability
- Use webhook-triggered and scheduled workflows together for responsive processing and reconciliation.
- Apply reusable authentication, error handling, checkpoints, correlation, and retry patterns.
- Keep vendor-specific endpoint details and field mappings configurable as Jira projects and APIs evolve.
Frequently asked questions
Jira Service Management can be integrated through its REST APIs, selected Jira Cloud webhooks, bulk or asynchronous issue operations, attachment APIs, OAuth 2.0, and API-token-based Basic Authentication. Scheduled JQL-based synchronization is useful for reconciliation and for changes not covered by webhook configuration.
Yes. Martini can consume Jira Service Management and Jira platform REST APIs, receive supported Jira webhook events, run scheduled reconciliation workflows, map Jira JSON payloads, and expose APIs that normalize or mediate JSM operations. No native Martini connector is documented in the supplied material.
No. A dedicated Jira Service Management connector is not required. Martini can use JSM's confirmed native REST APIs, selected webhook events, attachment endpoints, OAuth 2.0 or API-token authentication, and scheduled workflows.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Jira Service Management with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Atlassian, infrastructure providers, or other third-party systems based on subscriptions, usage, and deployment model.
REST APIs are the primary method for service requests, issues, customers, organizations, comments, queues, request types, SLAs, transitions, and attachments. Use webhooks for selected event-driven flows, bulk operations where applicable, and scheduled JQL reconciliation for completeness. A public JSM GraphQL or SOAP API should not be assumed.
Jira Cloud supports configurable webhooks for selected events such as issue creation and updates, comments, and worklogs. Coverage is event-specific and may not include every JSM state change, so important processes should combine webhooks with periodic REST-based reconciliation.
A Martini workflow can paginate through Jira responses, map issue-oriented JSM data to a canonical model, and use issue IDs, keys, request IDs, external IDs, and timestamps as correlation values. Idempotent upserts and checkpoints prevent duplicate requests when webhook delivery, scheduled polling, and API retries overlap.
Martini can separate authentication, permission, validation, missing-resource, rate-limit, and temporary-service failures, then apply bounded retries, backoff, logging, and replay workflows. It can also expose a controlled REST API that normalizes JSM request creation, status updates, comments, or lookup operations for downstream applications.
Related Martini documentation
Operations
Connect Jira Service Management with Martini
Use Martini to build maintainable Jira Service Management integrations across APIs, webhooks, scheduled workflows, applications, databases, files, and messaging systems.