APIForge
API-DESIGN

OpenAPI RFC 7807 Error Response Schema Example

Learn how to model RFC 7807 problem details error responses cleanly inside OpenAPI 3.0 specs.

Problem Statement

Inconsistent error payloads force client integrations to write custom, brittle try-catch parsers for every API endpoint.

❌ Anti-Pattern / Bad Implementation

Inconsistent error format returning plain text or non-standard keys.

bad-pattern.yaml
{
  "error": "something failed",
  "code": 500
}

✓ Refactored / Recommended Implementation

RFC 7807 compliant reusable OpenAPI problem details component.

good-pattern.yaml
components:
  schemas:
    ProblemDetails:
      type: object
      required: [type, title, status]
      properties:
        type:
          type: string
          format: uri
          example: https://api.example.com/errors/invalid-input
        title:
          type: string
          example: Invalid Input Parameter
        status:
          type: integer
          example: 400
        detail:
          type: string
          example: The provided email address is already registered.

How APIForge Checks This

  • Evaluates error response declarations across operations
  • Ensures 4xx and 5xx status codes are explicitly covered

Test your own OpenAPI specification against these checks

Paste any OpenAPI specification URL or YAML file into APIForge for instant 0-100 quality scoring, schema linting, and zero-CORS proxy testing.

Run API Score Check →
Share:𝕏 Postin Share