Build a verification workflow

Define the stages an API must pass before it counts as verified.

In short

A verification workflow is your organization's process for calling an API verified. It has stages in order, such as a manual review, a test run, test suites, or a contract or security check. Each stage says who approves. An API is verified only when one exact version of it passed every required stage.

Before you start

Who: changing workflows and policies needs "Run API verification". An Organization Admin or Manager holds it; a Member does not. Verifying by override needs "Override API verification", an Organization Admin permission.
Plan: verification is part of plans that include API verification (Plan & usage › Features).
First: decide the stages and who approves each. Nothing applies to an API until a policy points the workflow at it (see /help/api-testing/verification-policies).

Steps

Open API Tester, then "Ship" › "Verification", then "Workflows & policies".
Choose "Start from the recommended workflow", or "New workflow" for a blank one.
Add stages in order. Turn on "Runs together with the stage above" for stages different teams can do at once.
For each stage choose what happens, who approves (people, teams, roles or holders of a permission) and how many must approve.
Add automated checks where the stage needs evidence, and save.

Result: the workflow is ready for a policy to point it at APIs. See /help/api-testing/verification-policies.

Good to know

An API here is one saved request in one environment. Its version is what it sends, the environment, and the accepted response contract. Change any of that and the new version is not verified until the process says so again.
Required stages must finish before an API is verified. Optional stages never hold it back.
A stage set to "Only when…" is required only if its conditions hold, such as a security review only when authentication changed.
One rejection or request for changes decides a stage, whatever the rule.
Workflows and policies belong to the workspace, not to a project. The line under "Verification" says so: "Applies to every API in" your organization, or in your personal workspace, "not one project".

Testing is not approving Anyone who tests an organization's APIs can run and edit them, but only the reviewers a stage names can decide it. Changing workflows and policies needs the permission to manage API verification.

If something goes wrong

"Workflows & policies" is missing: you need the permission to manage API verification.
A workflow does not apply to any API: no policy points it at APIs yet.