Reparar JSON roto

Por qué el 'casi JSON' está en todas partes ahora

Desde que los modelos de lenguaje empezaron a generar salidas estructuradas como texto plano en lugar de mediante un esquema garantizado, buena parte del JSON que circula por los pipelines de automatización hoy viene de un modelo que se cortó a mitad de la respuesta, agregó un comentario suelto o envolvió el objeto en marcado de markdown por costumbre. Sume JSON editado a mano por alguien acostumbrado a los literales de objeto flexibles de JavaScript, o archivos de configuración copiados entre proyectos con una coma final sobrante, y un analizador estricto termina rechazando documentos que están a un arreglo pequeño y mecánico de ser perfectamente válidos. data.json_repair existe exactamente para esa brecha entre 'evidentemente pretendía ser JSON' y 'pasa JSON.parse'.

Qué se arregla y cómo lo recibe de vuelta

Envíe el texto roto por POST a /data/json-repair, y recibirá un task_id de inmediato mientras la reparación corre en segundo plano. Maneja directamente los patrones de falla más comunes: comas finales antes de un corchete de cierre, claves sin comillas o con comillas simples, corchetes de cierre faltantes por un flujo cortado a la mitad, y texto suelto como los bloques de markdown envolviendo el objeto. El JSON reparado y estrictamente válido —junto con un resumen de lo que se cambió— llega por webhook firmado o queda disponible en un enlace firmado válido por 24 horas.

Reparar frente a adivinar

Hay una línea importante entre corregir la sintaxis estructural e inventar datos, y este endpoint se mantiene firmemente del lado de la sintaxis: cerrar una cadena de texto sin terminar, agregar un corchete faltante, quitar una coma que no debería estar ahí son correcciones mecánicas y sin ambigüedad. No fabrica valores de campos faltantes ni adivina qué debía decir un valor truncado; si un valor en sí quedó cortado sin forma de recuperarlo, eso se reporta en lugar de inventarse, porque una herramienta de reparación que inventa datos en silencio es peor que una que falla ruidosamente.

Dónde encaja en un pipeline automatizado

El lugar natural para este endpoint es justo después de cualquier paso que produzca JSON sin garantía estricta de estar bien formado —analizar la respuesta de un modelo de lenguaje, ingresar una configuración mantenida a mano, o leer la salida de un script que no valida lo que escribe— y justo antes de que ese JSON llegue a código que de otro modo fallaría en el primer error de sintaxis. Como el precio es por solicitud más una tarifa por documento y un fallo nunca se cobra, resulta lo bastante económico como para correr como red de seguridad permanente sobre cada payload que recibe un pipeline.