api-testinglisted

Test backend HTTP surfaces — REST/RPC endpoints, Next.js route handlers, Supabase APIs, and Stripe webhook handlers — without a browser. Use this skill whenever the user wants to test an API, check an endpoint, verify a webhook, confirm RLS/auth behavior, validate response shape or status codes, or smoke-test the backend after a change. Trigger even if the user just says "does the booking endpoint still work" or "test the payment API" without naming a tool.
Marcdaou/claude-qa-suite · ★ 0 · API & Backend · score 70

Install: claude install-skill Marcdaou/claude-qa-suite

# API Testing Testing an API means proving that an endpoint behaves correctly across the cases that matter: the happy path, auth boundaries, bad input, and idempotency. The goal isn't to hit every URL once — it's to encode the *contract* of each endpoint as checks that fail loudly when the contract breaks. ## Workflow 1. **Discover the surface.** Find the endpoints worth testing. Look in `app/api/`, `pages/api/`, route handlers, Supabase RPC functions, and any Stripe webhook handler. Ask the user for the base URL (local dev vs. the live Vercel URL) and any auth token / API key needed. Never hard-code secrets into the suite file — reference environment variables instead. 2. **Write a suite file.** Express the tests as a JSON suite (schema below). One entry per case. Cover, per endpoint: - **Happy path** — valid request returns the expected status and body shape. - **Auth boundary** — the same request *without* a token (or with a wrong one) is rejected. For Supabase, this is where you catch missing RLS policies. - **Validation** — malformed/missing fields return 4xx, not 500. - **Idempotency** — for payment/booking creation, the same idempotency key doesn't double-charge or double-book. - **Webhooks** — a payload with a bad/missing signature is rejected; a valid one is accepted exactly once. 3. **Run it** with the bundled runner — it needs no dependencies (Python stdlib): ```bash python3 ${CLAUDE_PLUGIN_ROOT}/scripts/api/r