Validador de OpenAPI YAML

Pega tu openapi.yaml y el validador comprueba las partes que toda spec necesita: un campo de versión, un objeto info con título y versión, y un objeto paths. También avisa de las claves de ruta sin barra inicial y de las claves de operación que no reconoce.

Cómo validar un archivo YAML de OpenAPI

  1. 1

    Copia el YAML

    Copia el contenido completo de tu `openapi.yaml` o `swagger.yaml`, manteniendo la indentación exactamente como está.

  2. 2

    Pégalo en el campo

    Pégalo en el cuadro del documento OpenAPI / Swagger. En YAML la indentación es la estructura, así que no la reescribas ni la reformatees.

  3. 3

    Ejecuta la validación

    Continúa al paso de resultados y lee los errores y los avisos.

  4. 4

    Corrige y vuelve a comprobar

    Corrige cada elemento indicado en tu archivo, pega la nueva versión y ejecútala otra vez.

Por qué la indentación importa para el resultado

En YAML, el anidamiento de las claves decide a qué objeto pertenece cada campo. Si version está al mismo nivel que info en lugar de un nivel por debajo, el documento sigue siendo YAML legible, pero info.version falta y la comprobación lo informa. Lo mismo ocurre con paths: si una clave de ruta queda indentada bajo info por error, el objeto paths de nivel superior desaparece.

Usa espacios, no tabulaciones, y mantén un paso constante, por ejemplo dos espacios por nivel.

Un ejemplo práctico

openapi: 3.0.3
info:
  title: Pets API
paths:
  /pets:
    get:
      summary: List pets

El campo de versión, info.title y paths están presentes, y /pets empieza por barra con get como método conocido. Falta una cosa: info.version. El informe enumera:

Hallazgo Tipo
info.version es obligatorio. Error

Añade version: 1.0.0 bajo info, con dos espacios de sangría, y el documento se considera estructuralmente válido.

Mantén los documentos sencillos para una lectura fiable

La comprobación lee mejor los mapeos YAML habituales: líneas clave: valor sencillas, anidadas con una indentación constante. Si un documento con funciones avanzadas de YAML, como anclas o bloques multilínea, aparece como ilegible o muestra campos ausentes, prueba con una copia JSON de la misma spec para confirmar si el problema está en el contenido o en la sintaxis YAML.

Un resultado limpio confirma solo la estructura básica. No resuelve los enlaces $ref ni comprueba los esquemas.

Un flujo práctico para especificaciones YAML

Edita en pasos pequeños y vuelve a comprobar. Después de añadir una ruta nueva o mover un bloque, pega el archivo otra vez para detectar una mala indentación mientras el cambio sigue reciente. Cuando repartas una spec grande entre varios archivos, pega la versión combinada, porque esta comprobación solo lee el texto que le das y no carga otros archivos. Copia desde tu editor y no desde una página renderizada, ya que las páginas web pueden sustituir espacios y comillas por caracteres muy parecidos que cambian cómo se lee el YAML.

Por último, recuerda que el informe solo cubre lo que la comprobación puede ver. Un resultado limpio en un archivo YAML significa que el esqueleto de nivel superior es correcto, no que cada operación, esquema o referencia que contiene lo sea.

Preguntas frecuentes

Espacios. YAML no acepta tabulaciones para la indentación, y una tabulación puede hacer ilegible el documento o colocar los campos en el nivel equivocado.

Normalmente el campo está indentado en un nivel incorrecto, así que pertenece a otro objeto del que pretendías. Compara su indentación con la de la clave padre.

Esta comprobación solo busca que exista el campo openapi o swagger, no su valor, así que las versiones con y sin comillas pasan. Poner "2.0" entre comillas en Swagger sigue siendo una buena costumbre.

Sí. El documento se lee primero como JSON y, si falla, como YAML, así que cualquiera de los dos formatos funciona en el mismo campo.

Herramientas relacionadas

Herramienta disponible en otros idiomas

Guías y casos de uso