23 de septiembre de 2026
Respuestas vacías y errores de validación estandarizados
Tres ajustes en los formatos de respuesta de la API, para que todas las rutas sigan el mismo envoltorio:- Una respuesta vacía es
{ "response": null }. Eliminar una variable de entorno, guardar, mover y eliminar un archivo, quitar un dominio personalizado, limpiar la caché, quitar un webhook de despliegue y eliminar una aplicación respondían{}. Ahora responden{ "response": null }, igual que ya hacían las rutas de workspace. - El campo no válido pasa a
details.path. Un400 VALIDATION_ERRORincluía antespathsuelto en la parte superior de la respuesta; ahora llega como{ "code": "VALIDATION_ERROR", "message": "...", "details": { "path": "..." } }. - Los errores de cliente del gestor de archivos son
400, no500. Subir sin archivo (NO_FILE_UPLOADED) o un zip que no se puede leer (INVALID_ZIP_STRUCTURE) respondía500; ahora responde con el estado4xxcorrecto.
GET /v1/apps/runtimesresponde solo con{ "response": { ... } }, sin el campo extrastatus.PATCH /v1/users/mesolo aceptapt-br,en-usoes-esparalanguage.POST /v1/users/{id}/snapshots/{snapshot_id}/restorerechaza unresource_idno válido con400.POST /v1/orders/{orderId}/initiate/pixdevuelve siempretransaction_amountcomo número.
path en el nivel superior de un error, o trataba {} como éxito, actualízala a los formatos de arriba. Los tipos de @vertracloud/api-types ya describen el nuevo formato.También se estandarizaron los códigos de error relacionados con aplicaciones y bases de datos.Contenido de archivos siempre en base64
El contenido de archivo que devuelven Obtener contenido de archivo de la aplicación y los SDK ahora siempre es base64 estándar, y el camposize de la respuesta refleja el tamaño real en bytes del archivo, y no la longitud de la cadena codificada. Antes el formato variaba según el tipo de archivo. Si tu integración distinguía por formato de contenido, esa rama ya no es necesaria.