Overview

BesTest keeps your requirements, test cases, cycles and executions in one place inside Jira. This section is about reaching that same data from outside the app: from a script, a CI pipeline, or an AI agent.

There are two doors, and they open onto exactly the same data with exactly the same permissions:

Most teams end up using both. The pipeline writes results through the REST API every night, and a human asks the agent what the results mean in the morning.

One token, both doors

You do not need separate credentials. A single BesTest API token authenticates the REST API and MCP alike, and it is a bearer token you send in an Authorization header.

You create tokens yourself, from inside the app. See API tokens for the full walkthrough.

Three things about a token are worth knowing up front, because they shape everything else:

• A token reaches exactly one Space. There are no multi-Space tokens. If you automate two Spaces, you create two tokens. This is deliberate: it keeps revocation honest, so killing a token can never silently break something in a Space you were not thinking about.
• A token carries a permission level, either read only or read and write, chosen when you create it.
• A token always expires. The maximum lifetime is one year and there is no never-expires option.

Pick the right base URL for your region

BesTest runs separate, independent servers in three regions, and your data lives in exactly one of them. A token minted in one region does not work against another. If a call returns 401 and the token looks right, the base URL is the first thing to check.

Every path in this section hangs off that base URL:

Regional hosting is also why your data stays where you need it: an EU customer's requirements, test cases and results never leave the EU server. Other regions can be provisioned on request.

What the token can see

A token never grants more than the person who created it already has. It is not a service account and it is not an escalation path.

• The token is bound to one Space, so it cannot read or write anything in any other Space.
• Inside that Space, read only tokens can read everything you can read and change nothing. Read and write tokens can also create and update.
• Every write is attributed to the token's owner, so the history still shows a person, not an anonymous robot.

A Space admin can see every token pointed at their Space and can revoke any of them, which is the safety valve when someone leaves the team or a laptop goes missing. Admins cannot create, rotate, or reveal a token belonging to someone else.

Rate limits

Requests are limited to 100 per minute per token, and that budget is shared across the REST API and MCP: they are one bucket, not two. Over the limit you get an HTTP 429.

For bulk work there are batch endpoints that do the job in one request instead of thousands. See Bulk work without hitting the limit.

What it costs

Nothing extra. Programmatic access is included on every plan, the free tier included, with no per-call charge beyond the rate limit above.

Where to go next

1. Create your first token. Everything else needs one.
2. Copy a recipe. Complete flows for the jobs people actually automate: recording a CI run into a cycle, importing in bulk, gating a release.
3. Connect an AI agent if you want to ask questions in plain English. There are step-by-step guides for Claude Code, Claude Desktop, Cursor, VS Code, Codex, Grok and others.
4. Read the REST API guide if you are writing a script or a pipeline step.

Related

• Test automation - how CI results and coverage fit together
• AI-supported testing - what teams actually build with an agent
• What is MCP? - a plain-English primer if the term is new