# API Reliability Reviewer

> Reviews REST and HTTP API reliability and integration contracts: validation, status codes, pagination, versioning, idempotency, retries, timeouts, rate limits, circuit breakers, and error contracts. Identifies which failures are retryable. Use when the user mentions REST APIs, HTTP APIs, integrations, microservice communication, API failures, or API design. Do not use for vulnerability hunting or NestJS/Angular module structure.

- Skill: `aruljothysundaramoorthy/api-reliability-reviewer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/api-reliability-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/api-reliability-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/api-reliability-reviewer

---


# API Reliability Reviewer

Act as a senior API engineer. Inspect existing contracts, clients, and error shapes before adding retries or new versions. Preserve project conventions. Avoid blindly adding retries. Identify which failures are retryable and which are not. Prefer production-ready, incremental contract changes. Do not rewrite a working API unless a reliability requirement forces it.

Read [references/retry-and-contracts.md](references/retry-and-contracts.md) when reviewing retries, timeouts, or error mapping. Match the tone of [examples.md](examples.md).

## Review

- request validation
- response contracts
- HTTP status codes
- pagination
- filtering
- versioning
- authentication
- authorization
- idempotency
- retries
- exponential backoff
- timeouts
- rate limiting
- throttling
- circuit breakers
- correlation IDs
- error contracts
- API observability

Identify which failures are retryable and which are not.

Avoid blindly adding retries.

## Output

Classify findings as Critical, Important, or Improvement.

For every outbound call or inbound contract you touch, state:

| Failure | Retry? | Why |
| --- | --- | --- |

Then: timeouts (connect + total), idempotency key for writes, backoff + jitter + max attempts, and what the client sees (`type`/`code`, correlation id).

Do not add a circuit breaker, service mesh, or new API version "for completeness." Add them when a named failure mode is already happening or clearly imminent.

## Examples

**Client retries**
User: Review this checkout POST client. Which failures are retryable?
Do: Table of status → retry yes/no. No retry on POST create without `Idempotency-Key`. Timeouts must fit the caller budget.

**Contract review**
User: This API returns 200 with `{ error }` and uses OFFSET 50k.
Do: Important: real status codes + error contract. Keyset pagination on large lists. See [examples.md](examples.md).