Skip to main content
Cada error que devuelve la API de wondeya es un documento de problema con la misma forma, y todos llevan un code estable y legible por máquina. El código cliente ramifica sobre code. Nunca debe ramificar sobre detail, que es texto para humanos, localizado y libre de cambiar.

La envoltura

Las superficies pública y MCP envían este cuerpo como application/problem+json; las rutas de la consola envían el cuerpo idéntico como application/json. Todo lo que no es un error esperado se convierte en un 500 genérico con el código wondeya.internal.error. Los stack traces, los mensajes de base de datos, los prompts y los errores de proveedores externos nunca aparecen en una respuesta; van a los registros, indexados por el mismo requestId.

Códigos por área

Solicitud y transporte

Autenticación y sesión

Credenciales

Espacios de trabajo y membresía

Agentes

Proyectos (sitios) y sus direcciones

Páginas y tema

Chat

Planes y facturación

Onboarding

Conocimiento

Una fuente que falla después de haber sido aceptada no lanza un error: pasa a status: "failed" y lleva un motivo legible por máquina como unsupported_document, ingest_failed, fetch_timeout, fetch_dns_failed, fetch_response_too_large o fetch_blocked_address:link_local. Ramifica sobre esos de la misma forma, y muéstrale a una persona la versión traducida, nunca el código en crudo.

Recursos

Marca

Recursos genéricos

Dos hábitos que vale la pena tener

Trata los 404 idénticos como idénticos. Varios códigos colapsan a propósito situaciones distintas en una sola respuesta: «no es miembro» se lee igual que «no existe tal espacio de trabajo», y un host desconocido se lee igual que una página no publicada. Distinguirlos convertiría el endpoint en una sonda. No construyas una UI que adivine cuál fue en realidad. Guarda el requestId. Es el único asidero que ata un fallo que viste a los registros del lado del servidor de la misma solicitud.