---
name: API Testing
slug: api-testing-2
category: Quality
description: API Testing helps design test plans, cases, and risk analysis for REST, GraphQL, SOAP, gRPC, and WebSocket APIs. Use it when you need coverage for positive, negative, boundary, auth, and response validation scenarios.
github: "https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-testing"
language: Python
stars: 193
forks: 27
install: "npx degit https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-testing ~/.claude/skills/api-testing"
installs_to: ~/.claude/skills/api-testing
source_path: skills/en/testing-types/api-testing/SKILL.md
collection_size: 25
category_size: 1662
collection_url: "https://dirskills.com/collections/naodeng/awesome-qa-skills"
added: 2026-09-05T05:31:42.049Z
last_synced: 2026-09-05T05:31:42.049Z
canonical_url: "https://dirskills.com/skills/api-testing-2"
---

# API Testing

API Testing helps design test plans, cases, and risk analysis for REST, GraphQL, SOAP, gRPC, and WebSocket APIs. Use it when you need coverage for positive, negative, boundary, auth, and response validation scenarios.

**Install:**

```bash
npx degit https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-testing ~/.claude/skills/api-testing
```

## README

# API Testing (English)

**Chinese version：** See the corresponding Chinese skill.

## When to Use

- Need an API test plan, API cases, or API risk analysis.
- The request involves REST, GraphQL, SOAP, gRPC, WebSocket, or mixed API behavior.

## Workflow

1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
2. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
3. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
4. Default to Markdown; switch formats only when the user asks.

## Core Constraints

- Prioritize by risk / business impact — do not treat everything equally.
- Separate confirmed facts from current assumptions.
- Do not invent endpoints, fields, environments, or root causes the user did not provide.
- Keep output executable: concrete scenarios, clear priority, clear next steps.

## Progressive Disclosure

- Before producing output, read and follow `prompts/api-testing.md` (minimum coverage, output structure, quality bar).
- When Excel/CSV/JSON/Word is requested: read `output-formats.md` and honor the format.
- When a ready-made template fits: use matching files under `output-templates/`.
- For deep framework/troubleshoot/schema notes: read only the relevant file(s) under `references/`, do not load the whole directory.
- For format conversion or helper checks: prefer existing `scripts/` over reinventing.
- For evaluating/regressing this skill: use `evals/` with skill-up.

## Pre-delivery Checklist

- [ ] Followed the main prompt's output structure
- [ ] Minimum coverage focus: endpoints or business flows in scope, priority and risk level, positive scenarios, negative scenarios, boundary scenarios, auth and permission checks, request and response validation, error handling, ... (details in main prompt)
- [ ] Covered the minimum checklist, or explained omissions
- [ ] High-risk items have explicit priority
- [ ] Did not invent details the user did not provide
- [ ] Assumptions and gaps are marked

## Common Pitfalls

- Do not pretend completeness when scope/context is missing.
- Do not treat every item as equally important.
- Do not skip assumptions and information gaps.
- Do not dump generic theory unrelated to the current toolchain.