Jira integration
Push meeting output into Jira the way Jira expects it.
Backlog.cloud turns meetings into stories, bugs, tasks, epics and spikes, then pushes them to Jira Cloud over REST v3 with descriptions written in Atlassian Document Format. Issue types map per project, labels carry through, and the whole push respects Jira's rate limits. You review everything first.
Atlassian Document Format
Descriptions in ADF, not Markdown
Jira Cloud's v3 API takes descriptions as ADF, a typed JSON document. It does not take Markdown. Most "export to Jira" features get this wrong and ship tickets full of literal asterisks and hash signs that someone then has to reformat by hand.
Backlog.cloud converts each item's structured body straight into ADF nodes. Section headings become heading nodes. Bold labels become text with a strong mark. Steps to reproduce, scope lists and dependencies become bullet lists. The issue is readable the second it appears, with no cleanup pass.
Acceptance criteria are written as numbered Gherkin scenarios under their own Acceptance Criteria heading in the description, exactly where an engineer picking up the story expects to find them. The same body carries a Traceability section naming who raised the item, so the ticket can answer for itself.
{
"version": 1,
"type": "doc",
"content": [
{ "type": "paragraph",
"content": [{ "type": "text",
"text": "As a customer upgrading my plan..." }] },
{ "type": "heading", "attrs": { "level": 2 },
"content": [{ "type": "text",
"text": "Acceptance Criteria" }] },
{ "type": "bulletList",
"content": [
{ "type": "listItem", "content": [
{ "type": "paragraph", "content": [
{ "type": "text",
"text": "1. Given an annual customer..." }
] } ] }
] }
]
}Field mapping
Exactly what maps to what
One issue per artefact, created against the Jira project key you configure. No hidden fields, no surprises in the payload.
| Backlog.cloud output | Jira field | Detail |
|---|---|---|
| Generated title | summary | Capped at 254 characters on a word boundary. Jira hard-rejects 255+. |
| Description and structured sections | description | Written as an ADF document: headings, paragraphs, bold runs and bullet lists as typed nodes. |
| Artefact type | issuetype | Mapped per project. Defaults below, every one remappable. |
| Priority | review queue | Guides review and ordering. Your Jira priority scheme stays untouched. |
| Acceptance criteria | description section | Numbered Gherkin scenarios under an Acceptance Criteria heading. |
| Labels | labels | Type label plus domain tags, whitespace converted to hyphens, optional prefix. |
| Traceability | description section | Names who raised the item and where, so the ticket answers "who asked for this?". |
Issue types
Seven artefact types, mapped per project
These are the defaults. An organisation admin can remap any of them to your own issue type names, useful when your Jira project calls spikes "Research" or has a custom Requirement type.
| Artefact | Default Jira issue type | What travels with it |
|---|---|---|
| User Story | Story | INVEST-shaped, Gherkin acceptance criteria |
| Bug | Bug | Observed and expected behaviour, steps to reproduce |
| Task | Task | Goal, context, deliverable |
| Epic | Epic | Hypothesis, MVP scope, success metrics |
| Spike | Spike | Timebox, key questions, exit criteria |
| Requirement | Task + requirement label | Jira has no native requirement type. Remap to a custom type if you have one. |
| Action item | Task + action-item label | Owner and due context in the description. |
RAID entries, decision logs and meeting minutes do not push to Jira because Jira has no sensible home for them. They live in Backlog.cloud, push to Notion, or export directly. Process models download as BPMN 2.0 XML and Discovery Packs export as .docx.
The push, step by step
Review first, then a push that finishes what it starts
1. Review queue
Generated items wait in Backlog.cloud with the verbatim quote each one was extracted from. You edit, discard or approve. Nothing reaches Jira that a human did not look at, unless you deliberately switch a project to auto-push later.
2. Batched, serial push
Select up to 200 items and push them as one job. A queue works through them one at a time with live progress, and you can cancel mid-job. Items that were already pushed are skipped, not duplicated.
3. Rate limits respected
Jira Cloud runs a points-based budget: 65,000 points per hour in a global pool per site. The serial worker paces requests to stay well inside it, and if Jira does return a rate-limit response the job stops cleanly. Retrying skips anything already pushed, so nothing lands twice and nothing is silently dropped.
4. A link both ways
Every pushed item records its Jira key, like PAY-214, and a link to the issue. If an auth token has been revoked, the job stops immediately with a clear connection error instead of failing item by item.
Auth and permissions
OAuth 2.0, per user, no pasted API tokens
You connect Jira by authorising Backlog.cloud against your own Atlassian account. There is no shared service account and no long-lived API token sitting in a settings form. Access tokens are stored encrypted and refreshed shortly before they expire, so pushes do not fail mid-job because a token aged out.
Revoking access from the Atlassian side works the way you would hope: the next push attempt detects the dead token, marks the connection as broken, and stops. Reconnect in two clicks and push again. Field mappings are managed by organisation admins, so a team member cannot quietly repoint a project at the wrong Jira key.
Jira is one of six destinations. Backlog.cloud pushes to Jira, Azure DevOps, Linear, GitHub Issues, Notion and ClickUp, and the full list lives on the integrations overview.
FAQ
Jira integration, answered
- Why does Jira need ADF instead of Markdown?
- Jira Cloud REST v3 only accepts descriptions as Atlassian Document Format, a typed JSON tree. Send Markdown and you get a wall of unrendered asterisks. Backlog.cloud builds the ADF document directly: headings become heading nodes, bold runs become strong marks, and lists become bulletList nodes, so the issue reads properly the moment it lands.
- Which artefact types push to Jira?
- Seven: user stories, bugs, tasks, epics, spikes, requirements and action items. Stories, bugs, tasks, epics and spikes map to native issue types. Requirements and action items land as Tasks with a distinguishing label because Jira has no native concept for them, and you can remap either to a custom issue type in the per-project mapping.
- Do items go straight into Jira after a meeting?
- Not unless you tell them to. Items land in a review queue first, each carrying the verbatim quote it was extracted from. You edit, discard or approve, then push. Once a project has earned your trust there is a per-project auto-push setting that queues approved output automatically.
- How are Jira Cloud rate limits handled?
- Jira Cloud allocates a points budget of 65,000 points per hour across your site. Backlog.cloud pushes serially from a queue, paces requests to stay inside the budget, and batches the job as one unit with live progress. If Jira rate limits anyway, the job stops cleanly and a retry skips anything already pushed, so a big refinement session lands completely and never lands twice.
- What happens if an item was already pushed?
- Every pushed item records its Jira key and URL. If an item already has one, the queue skips it and shows you the existing link instead of creating a duplicate issue.
- What does the OAuth connection actually get access to?
- You authorise Backlog.cloud against your Atlassian account with OAuth 2.0, per user, no shared service account and no API token pasted into a form. Tokens are stored encrypted and refreshed shortly before they expire. Revoke access in Atlassian and the next push stops immediately with a clear connection error.
- Can I control which Jira project issues land in?
- Yes. Each Backlog.cloud project maps to one Jira project key, set by an organisation admin. The mapping also holds your issue type choices, an optional label prefix and an optional default assignee.
- Does the meeting bot part work with my calls?
- The meeting bot joins Zoom, Microsoft Teams and Google Meet from a pasted link, and the Team plan adds Google Calendar and Outlook auto-join. You can also paste a transcript or upload audio, video, images or text files. Every input route ends at the same review queue and the same Jira push.
Keep going
Related workflows and resources
Meeting to Jira
The full workflow from a live call to reviewed issues in Jira.
Free Jira ticket generator
Paste notes, get ticket drafts in the browser. No account needed.
Sprint planning meetings
What Backlog.cloud listens for in sprint planning specifically.
User stories
The INVEST structure and Gherkin criteria behind every pushed story.
Azure DevOps integration
The same pipeline pointed at work items instead of issues.
Linear integration
Issues with team targeting and markdown descriptions.
Connect Jira and push your next meeting
Create a free account, run one meeting or transcript through it, and push the reviewed output to Jira. 3 free generations, no card.