Documentation

SPIREX documentation

How every SPIREX feature actually works, written for the people using it, not a marketing summary. Each page documents the mechanics in detail and answers the questions people actually ask about it.

Sprint boardsHow sprint boards, backlog grooming and carry-over actually work in SPIREX: setting up a sprint, working the board, and closing it without losing work.01
Workflows & epicsHow the work hierarchy, the visual workflow editor, issue linking and the rich TipTap editor work in SPIREX, with the six core statuses your columns map to.02
Time tracking & reportingHow worklogs, the three report views and CSV export work in SPIREX, and why estimates are never blended with logged time in a report.03
Jira importThe mechanics of the SPIREX Jira importer: connecting Atlassian, what converts and what does not, epic-link resolution, and ghost users for unmatched people.04
AI ticket draftingHow SPIREX drafts tickets from text, an image, a document or a live voice call, what model powers it, and what the free-tier AI-action quota means.05
REST APIHow SPIREX API keys, the X-Org-Id multi-tenant model and role-scoped permissions work, and what the REST API can read and write today.06
Roles & permissionsHow roles and permissions work in SPIREX: org-level roles, project-scoped access, admin and superadmin boundaries, and what each role can actually do.07

Frequently asked questions

Yes. Every page here is public: no sign-up required to read how a feature works. Creating a workspace is only needed to actually use the feature.

Each page carries a visible "Published"/"Updated" date matching what actually shipped in the product at that time. Where a feature has a known limitation (kanban, for example), the docs say so rather than describing an aspirational version.

The public REST API page here covers authentication and permissions. The complete endpoint-by-endpoint reference lives in-app at /api-docs once you have an account and an API key, since it documents behaviour tied to a real key.

See it running on your own data

Reading how a feature works is one thing. A free workspace with a real Jira import is the fastest way to check whether it actually holds up.

Start freeView the source