Read.ai to Jira

Turn Read.ai meetings into Jira issues

Read.ai records and summarises the meeting. Jira needs a typed issue with acceptance criteria in the right project. Spectr is the bit in between: it reads the Read.ai summary and the speaker-labelled transcript, pulls out a structured spec, drafts a story per item, and publishes the approved ones to Jira as issues your team can actually pick up.

How it connects

Read.ai: OAuth. You authorise Spectr from Read.ai's consent screen; Spectr refreshes the connection itself and never asks for a password. Jira: OAuth 2.0 (3LO). You pick the Jira site on Atlassian's own consent screen. Spectr requests read and write access to Jira work plus read access to users, and refreshes the token itself.

Before you start

No plan requirement. Connections are configured per project, and every credential is encrypted at rest.

Speaker attribution survives the trip

Read.ai's transcript records who said what, and Spectr keeps that through to the spec. So a requirement can be traced back to the person who raised it - which is the difference between "the client asked for this" and something nobody can check three weeks later. On the Jira side, each story gets a real issue type from your project, priority matched to your own scheme, and sub-tasks where one requirement produced several stories.

What Spectr reads from Read.ai

Meeting summary: Read.ai's own summary is imported as the leading section, so the most condensed account of the call is what the model reads first.
Speaker-labelled transcript: The full transcript with speaker turns preserved, so a requirement can be traced back to who raised it.

What Spectr writes to Jira

Issues, only after approval: Nothing reaches Jira until a person approves it in Spectr's review step. Descriptions and acceptance criteria are converted from markdown to Jira wiki markup on the way in, so headings and lists render as headings and lists instead of raw syntax.
Type, priority, labels and estimates: Feature maps to Story, bug to Bug, chore and spike to Task - resolved against the project's real issue types. Priority maps by name against your instance's own priority scheme. Labels are slugified because Jira rejects spaces in them. Estimates use your site's story-points field when it exists.
Parent and sub-task nesting: When a spec-sheet task generates several stories, Spectr creates one parent issue and nests the rest as real Jira sub-tasks. If the project has no sub-task type, it publishes flat rather than failing.

A person approves everything before it is published

Spectr generates specs and stories, then stops. Every story goes to a review page where you approve it, edit it inline, or reject it - individually or in bulk. Only approved stories reach an issue tracker. There is no auto-publish setting to switch on, because a backlog nobody read is not a saving.

Setting it up

In Spectr, open the project you want to connect and go to Integrations.
Choose Read.ai, click Connect, and approve access on Read.ai. Spectr refreshes the token from then on.
Choose Jira, click Connect, and pick the site on Atlassian's consent screen.
Pick the Jira project new issues should land in - and optionally a default issue type and starting status.
Import a meeting from Read.ai. Spectr gathers project context, extracts a structured spec, and writes a story per item.
Review the generated stories - approve, edit inline, or reject - then publish the approved ones to Jira.