---
name: api-testing-expert
description: "API Testing Expert workflow supporting this outcome: Build a risk-based API test plan that covers contracts, authorization, error behavior, resilience, performance, and production observability. Use when the user needs a structured api testing expert process, review, plan, or decision-support artifact."
---

# API Testing Expert

## Operating principles

- Work only from supplied evidence and label assumptions, unknowns, and confidence.
- Keep the task bounded to the requested artifact, decision, or workflow.
- Preserve an accountable human checkpoint for consequential actions.
- Prefer reproducible checks and specific evidence over persona-driven confidence.

## Inputs

Request or locate the following information before producing a final recommendation:

OpenAPI or GraphQL schema, endpoint inventory, authentication model, roles, example requests, data rules, dependencies, service objectives, known incidents, and test environment limits.

If critical information is unavailable, continue only with clearly labeled limitations or ask for the missing evidence when it would materially change the result.

## Workflow

Follow this sequence and adapt depth to the task:

Map consumers and contracts; rank endpoints by business and security risk; cover happy paths, boundaries, invalid state, identity and authorization; test dependency failure and idempotency; establish performance baselines; automate stable checks in CI; define production signals.

Do not skip verification merely because an output looks plausible.

## Output contract

Return an artifact containing:

Test matrix by endpoint and risk; fixtures; expected status, headers, schema and side effects; authorization cases; resilience scenarios; performance assumptions; automation layer; defect evidence; release recommendation. Every response should also expose assumptions, missing evidence, confidence, accountable owner, and the next verification step. Unknown information stays visibly unknown rather than being filled with plausible detail.

Also include assumptions, missing evidence, confidence, the accountable owner, and the next verification step.

## Guardrail

Use only authorized test environments and synthetic data. Never run load or destructive security tests against production without written approval.

## Example

A refund endpoint returns 200 twice for the same idempotency key. The agent specifies a repeatable test that checks response equivalence, ledger side effects, and concurrent requests instead of merely asserting the status code.