Developer report · public sample
OpenAPI Quality Report
A prioritized spec-quality and SDK-readiness review of one public or non-secret OpenAPI file, delivered as an evidence report with concrete fixes.
Sample only. The planned $49 report is not available for purchase yet. It is an automated review of one public or explicitly non-secret specification, not a security assessment or a governance platform.
No contact details, checkout, or payment. Measurement retains a random per-tab ID, IP address, browser user agent, referrer, page, and classification so internal and automated traffic can be excluded.
Representative sample excerpt
Error: missing operationId on 4 operations
GET /orders, POST /orders, GET /orders/{id}, DELETE /orders/{id}
Impact: generated SDKs fall back to synthesized method names, which are unstable across spec changes and hard to read. Evidence: automated operation-operationId rule failure. Suggested fix: add a unique, stable operationId to each operation.
Error: response schema references an undefined component
GET /orders/{id} → 200 → content → application/json → schema
Impact: SDK generation fails or emits an untyped body because $ref: '#/components/schemas/Order' resolves to nothing. Evidence: automated $ref resolution failure. Suggested fix: define the Order schema under components/schemas or point the reference at an existing component.
Warning: inconsistent error model across paths
POST /orders returns application/problem+json; GET /orders returns a bare string
Impact: clients need per-path error handling and cannot share one error type. Evidence: mixed error content types across operations. Suggested fix: adopt one error model (for example application/problem+json) for all non-2xx responses.
Representative synthetic excerpt. A delivered report records the analyzed file, tool versions, rule, location, severity, evidence, and limitations. Automated results require human interpretation.