Request and response examples for API endpoints
Why it matters
REST and GraphQL API consumers can't integrate correctly without knowing exactly what to send and what to expect back. Documentation that describes an endpoint without showing an example request and response forces developers to guess at header formats, body structure, and response shapes — every guess is a potential bug. OpenAPI specs with 'string' placeholders for every field value are no better than no docs at all: they show structure but not semantics, valid values, or what realistic data looks like. iso-25010:2011 analysability requires that a system be understandable without probing it experimentally.
Severity rationale
High because API consumers who cannot see example request and response payloads must probe the API experimentally, introducing integration bugs and making the first-use experience unreliable.
Remediation
For each endpoint, show a complete curl request and the matching response with realistic (not placeholder) field values:
### POST /api/users
**Request:**
```bash
curl -X POST https://api.example.com/api/users \
-H "Authorization: Bearer sk-..." \
-H "Content-Type: application/json" \
-d '{"name": "Jane Smith", "email": "jane@example.com"}'
Response (201):
{
"id": "usr_abc123",
"name": "Jane Smith",
"email": "jane@example.com",
"created_at": "2026-03-29T12:00:00Z"
}
Never use 'string' or 'value' as example field values — use realistic data that shows the actual format consumers will receive.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Developer Documentation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.analysability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from developer-documentation·automated