API integration for Jira
We build your Jira connector
We wire Jira Cloud into your product: support opens the ticket from the file, Done closes the job in the ERP, the customer follows without opening Jira.
- Senior product team
- Jira connectors in production
- from scoping to monitoring
What does the Jira API provide and why integrate it into your platform?
Jira is the most widely used ticket tracking tool by technical teams. Its API lets your application create an issue with business context, follow transitions, and react when status changes. You integrate it so all of that lives in your product: support ticket opened from the file with no copy-paste, Done that closes the job in the ERP, Engineering bug created with context already there, customer portal that shows progress without exposing Jira. Same system: Jira stays the eng tool, your application stays the business journey.
What Jira changes in your platform
Support ticket created from the customer file
Contract, order, logs: the Support issue is born from your product. No more copy-paste from the ERP into Jira.
Done that closes the job in the ERP
The transition becomes a business event. The technician does not retype: the file closes in the same system.
Product bug into Engineering, context included
Replay, URL, account: the issue opens complete. No empty title and no second qualification process.
Customer portal without exposing Jira
The customer follows their report in your interface. Jira stays on the eng side; the journey stays in your platform.
What it changes in your product
Engineering in service of a measurable result: ticket from the file, Done that closes the ERP, portal without exposing Jira.
Support no longer opens Jira by hand
Customer, contract, URL, logs: the issue is born from the file. Qualification time drops before assignment.
The ERP updates when Jira moves
In Progress, Done: each transition can open or close the job. No double entry.
The customer follows without leaving your product
The portal shows progress. Jira stays the eng tool, not the customer journey.
Engineering gets the bug already contextualised
Replay, URL, account: no more orphan ticket to rebuild before work starts.
How we ship your Jira connector
Scoping
Where Jira enters your product: support, Engineering, customer portal, ERP close. Cloud or Data Center, auth, point budget. Settled before coding.
Mapping
Field mapping to your business objects, JQL, unique identifier for upsert. Webhook traps (Create post-function) are listed here.
Development
A connector wired into creation from the file, transitions and the portal. Webhooks rather than polling, HMAC, queue, 30-day extend.
Monitoring
Point consumption, 429s, expired webhooks, issue.id dedup. Alert before the hourly cap, not after.
What the API brings to your platform
- Create the issue from the business file
- Contract, order, URL, logs in the fields. Business identifier for upsert: no more orphan ticket.
- Push transitions back into the ERP
- Webhooks filtered by JQL: Done closes the job. Primary in 30 s, secondary 15 min, Cloud retries.
- Feed the portal without exposing Jira
- JQL on reporter or account field. The customer reads progress in your product.
- Hold the point quota in production
- 65,000 points/h tier 1 (Forge, Connect, 3LO). Webhooks rather than /search polling, OAuth extend at 30 days.
Jira API vocabulary
- Points / hour
- Since 2 March 2026, Forge, Connect and 3LO consume a point quota, not a plain request counter. A read costs 1 point per business object. Tier 1: 65,000 points/hour shared across all tenants.
- Extend webhook life
- A webhook registered over REST (OAuth) expires after 30 days. Without an extend cron, the app goes mute. This is not an ops detail, it is a deliverable.
- X-Hub-Signature
- HMAC for Cloud webhooks, documented 2024+. Data Center: retries often missing, HMAC depending on version. An on-prem client is not « the same API ».
- API token vs app
- API token traffic is not under the point quota. An internal token script is not a multi-tenant product. Do not sell a Marketplace app designed as a token.
- jira:issue_created
- The event to use on create. A post-function on Create Issue does not fire the webhook. It is in the docs, it is still the first staging incident.
- external_id
- Your business identifier in a unique Jira field. Without it, every retry creates a duplicate. Upsert is on this field, not on the summary.
The real constraints of the Jira API
2 March 2026 changed polling
A JQL of 1,000 issues costs ~1,000 points. Naive apps saturate before noon UTC. Webhooks, not a /search scan every minute. Internal tokens stay outside the point quota.
OAuth: 5 webhooks and 30 days
An extend cron is mandatory. Connect offers 100 webhooks, a different model. Forget the extend and the app goes mute with no visible business 4xx.
Cloud is not Data Center
Webhook retries, HMAC, quotas: the quote splits them on page one. Sticking an on-prem client onto a Cloud connector is not a URL change, it is a second project.
Create and post-function stay silent
Use jira:issue_created. Project deletion in cascade can omit issue_deleted. These traps are in Atlassian docs, not integrator folklore.
Jira webhooks or periodic JQL search?
Two ways to keep Jira in sync with your business. Since 2 March 2026, naive polling is no longer a comfort choice.
| Criterion | WebhooksReal time | JQL pollingCron /search |
|---|---|---|
| Point cost | The useful event | 1 point × every issue read |
| Delay | Seconds (primary 30 s) | The cron period |
| OAuth quota | 5 webhooks, expire in 30 d | Burst + /search points |
| Create trap | issue_created, not post-function | None, but expensive |
| Initial sync | Completed by a bounded import | Often the real point killer |
| Internal token | UI / Connect webhooks | Outside point quota, not a product |
| The right case | Product, ERP, portal | One-off internal script |
The initial sync is costed in points before it is launched. A webhook without a 30-day extend is involuntary polling: the app goes mute. We put both in the operations deliverable.
What we measure on a Jira integration
The other productivity tools
Jira is combined more often than it is replaced. These options are discussed at scoping.
We combine Jira with
The stack around Jira when we wire it into a product or an ERP.
Jira: your questions
We wire it into your product touchpoints: issue creation from the support file, transitions that close the ERP, customer portal without exposing Jira. Technically: split Cloud and Data Center, choose auth (internal token or OAuth/Forge/Connect), JQL webhooks rather than /search polling, HMAC, queue, 30-day extend, unique business field for upsert. The sensitive part is not POST /issue, it is the product journey, the point budget and the Create post-function trap.
No. Cloud REST v3 is not the Data Center API. On Cloud: webhook retries up to 5 times, HMAC X-Hub-Signature, point quota since 2 March 2026 for Forge, Connect and 3LO. On DC: retries often missing, HMAC depending on version, a different distribution model. An on-prem client is not a URL change. We split it at scoping, and we do not sell a Marketplace app designed as an internal token. The quote states Cloud or DC before the first line of code.
Forge, Connect and OAuth 3LO consume points per hour, not only requests. Default tier 1: 65,000 points/hour shared across all tenants. A business-object read costs 1 point, an identity 2, a write 1 base point. A JQL that returns 1,000 issues costs ~1,000 points. API tokens stay on the historical burst: useful internally, not a multi-tenant product. We estimate the initial sync before launching it, and we prefer webhooks to cron.
That is the REST OAuth contract: 5 webhooks per app, per user and per tenant, 30-day expiry, Extend webhook life operation. Without a cron, the app goes mute with no business 4xx. Connect goes to 100 webhooks, a different model. Primary: 30 s delivery, 20 in parallel. Secondary (bulk): 15 min, 10 in parallel. Body > 25 MB not delivered. We put the extend, the dedup and the expiry alert in the operations deliverable, not in a forgotten runbook.
A first useful flow, typically issue creation from your business file with the matching field, ships in two to three weeks. A complete chain with transitions into the ERP, customer portal, several projects and Marketplace OAuth is closer to six to eight weeks. Duration depends mainly on the touchpoints to wire, the mapping and the point budget. We scope the perimeter up front and give a firm estimate before we start.
A Jira integration project?
Let's talk. 30 minutes to scope where Jira enters your platform (support, Engineering, portal, ERP) and tell you frankly what holds without polling.
Discuss my Jira project