Release Verdict: Is This API Ready to Release?

A test report tells you what passed. The release verdict tells you whether to ship. It answers one question for an API, or for a whole project: is it ready to release, and why?

The four answers

An API nobody has tested is not marked as failing, and it is not marked ready either. Its verdict is No evidence yet.

Where to find it

• One API: open the API's page. The verdict is at the top of the Overview tab.
• A whole project: open the project's APIs screen. The card at the top gives the project's answer and lists the APIs in the way, worst first.
• One environment: type an environment name in the card and press Check. Only runs made there count.

Reading a verdict runs nothing and changes nothing. It is judged from results the product already holds: test runs and their failure causes, security findings, load results, mocks and pending specification changes.

What counts

The worst result wins, so a clean security result never hides a failing test. A failure caused by a down target, a gateway page, a wrong address or bad test data means the API never got a fair test. It counts as missing evidence, not as a failing API. A defect in the API blocks, and the product never rewrites a test to accept it.

If you cannot read a section, such as security findings, that section is left out and the verdict is marked partial. If your licence does not include the performance or security add-on, those checks are not counted, and the verdict says so.

The release policy

Every project is judged by a release policy. Until you save one, the cautious defaults apply. Under the project's verdict card, open What a release needs to set:

• Functional: require tests, require a run, require every test to have run.
• Security: for each severity, whether it blocks, is only a risk, or is ignored.
• Performance: whether a failed load test blocks, and whether a load result is required.
• Root causes: whether a defect found by run triage blocks.
• Changes: whether a pending breaking change blocks.
• Evidence age: how old a result may be, from 1 to 365 days (default 30).

A policy is saved only if every rule in it is valid. Changing the rules does not change verdicts that were already kept.

Keep a verdict as a record

Press Keep this verdict when a release decision is made. The product computes the verdict again and keeps it together with the policy it was judged by.

• A kept verdict cannot be edited or deleted through the product.
• The records of one API, project and environment form a hash chain: each record holds the fingerprint of the one before it, so a change or a removal shows up when the chain is checked.
• Each record says who asked: a person, a pipeline or an AI agent.
• The activity feed announces a kept verdict, and the API's Changes tab lists it.

Reports and the audit bundle

• Download report (PDF) gives a readable report: the verdict, what to do first, and every API with the reasons for its result.
• Download audit bundle (ZIP) contains:
  • the kept record and its policy;
  • a check of the whole chain;
  • the tests, runs, failure causes, changes and accepted risks the verdict rests on;
  • who asked;
  • a manifest with the SHA-256 of every file.
• The bundle lists the OWASP API Security Top 10, SOC 2 and ISO/IEC 27001 topics the evidence relates to. That list shows where the evidence belongs. It does not say a control is met, and it is not a certification.

In your pipeline

Open a test pack, choose Run in your pipeline, and tick Also ask whether the project is ready to release, and fail the build if it is not. You choose:

• When to fail. The default is on "not ready" or "no evidence yet", because an untested API is not a pass. You can switch to "only when not ready" or "anything but ready".
• An environment, so only runs made there count.
• A pull-request comment on GitHub, GitLab or Azure DevOps. It is updated on every push. Jenkins does not post comments.
• Keep the answer as a record, labelled with the build number.

If the verdict cannot be read, for example because the edition does not include it, the build fails rather than passes. See the GitHub Actions, Azure DevOps and Jenkins guides.

What it does not do

• It does not run, generate or edit a test. Run the tests first, then ask for the verdict.
• It is not a score. There is no percentage, only an answer and its reasons.
• It does not decide for you. A risk a person accepted is shown as a risk, in their words, until the acceptance ends.

Related articles

• Run triage: understand why a run failed
• Test validity and requirement verdicts
• MCP server