Cómo retirar versiones antiguas de una API sin romper integraciones web

Una versión antigua de una API puede seguir disponible mucho después de una migración web, un cambio de CRM o la implantación de un nuevo checkout. El problema aparece cuando nadie puede confirmar qué aplicación, proveedor o automatización la consume. Apagarla sin comprobarlo puede interrumpir pedidos, formularios, sincronizaciones o altas de clientes; mantenerla sin control prolonga una superficie de exposición que la empresa no conoce bien.

Retirar versiones antiguas de una API exige tratar el cambio como una tarea de operación y seguridad, no como una simple eliminación técnica. El objetivo no es desconectar todo lo que parezca obsoleto, sino disponer de evidencia suficiente sobre su uso, su responsable, los datos que mueve y la posibilidad de volver atrás si un proceso crítico falla.

El problema: una integración heredada que nadie se atreve a apagar

Es habitual encontrar rutas como /v1/, subdominios de pruebas, conectores creados por una agencia o endpoints que sobrevivieron a una renovación de WordPress o de una tienda online. Que una API esté documentada no significa que siga activa, y que no aparezca en la documentación tampoco demuestra que pueda retirarse. La pregunta útil es quién la utiliza, para qué proceso de negocio, con qué frecuencia y bajo qué responsabilidad.

OWASP identifica la gestión inadecuada del inventario como un riesgo específico para las APIs. Entre los problemas asociados incluye desconocer qué versiones están operativas, qué entorno las ejecuta, quién debe acceder a ellas o cómo retirar versiones antiguas. También recomienda valorar el riesgo de las versiones anteriores cuando las nuevas incorporan mejoras de seguridad. [1]

Crear un inventario mínimo que sirva para decidir

El inventario no tiene que convertirse en un proyecto documental interminable. Para cada API, host, endpoint relevante o integración conviene registrar un identificador, URL o dominio, entorno, versión, fecha prevista de revisión, responsable técnico, responsable de negocio y proveedor externo si lo hay. Debe quedar claro además qué sistema envía la información y cuál la recibe.

Añada una clasificación práctica de los datos intercambiados —operativos, personales, comerciales, credenciales o pagos—, el método de autenticación, la ubicación segura de las credenciales y el nivel de exposición previsto: público, interno o limitado a socios concretos. Complete cada ficha con evidencia de uso reciente y su origen, como registros del gateway, del servidor, de la CDN o de la aplicación. NIST contempla inventarios de software, servicios, aplicaciones personalizadas, servicios API y servicios cloud, y señala la necesidad de asignar responsabilidades y actualizar el inventario durante cambios y retiradas. [2] [3]

• Identificador, URL o host y versión.
• Entorno: producción, preproducción, pruebas o desarrollo.
• Propietario técnico, propietario de negocio y proveedor, si aplica. Intercambios de datos y consumidores conocidos. Evidencia de uso, fecha,

Comprobar qué está activo sin afectar al servicio

Contraste el inventario con fuentes de observación autorizadas, como logs de acceso, métricas del gateway, eventos de la aplicación o registros de infraestructura cloud. No hace falta realizar pruebas intrusivas ni explorar sistemas ajenos. Busque solicitudes recientes, origen de las llamadas, códigos de respuesta, cuentas de servicio y procesos de negocio relacionados. Si no hay trazabilidad suficiente, la integración no está lista para apagarse: queda pendiente de confirmación.

Una clasificación sencilla reduce decisiones ambiguas. Marque cada elemento como activa y aprobada cuando tiene uso, responsable y mantenimiento conocidos; en migración si hay consumidores identificados y fecha de cambio; pendiente de confirmación cuando la evidencia no permite decidir; o retirable cuando no hay uso confirmado, el responsable aprueba la baja y existe una reversión definida. Por ejemplo hipotético, si un endpoint de catálogo no recibe llamadas en el periodo de observación acordado, pero un proveedor no ha confirmado su sustitución, debería seguir pendiente de confirmación, no declararse retirado.

Retirar la versión con una secuencia de cambio controlada

Antes de desactivar una versión, confirme quién asume la decisión técnica y quién valida el impacto de negocio. Identifique consumidores internos, integraciones de terceros y automatizaciones aparentemente menores, como un formulario que crea contactos o una tarea que actualiza existencias. Comunique una fecha, un canal para incidencias y el alcance exacto del cambio. Una ventana de observación acordada permite detectar dependencias sin convertir la retirada en un apagado improvisado.

Aplique el cambio en un momento previsto por la empresa y verifique los flujos críticos que pudieran verse afectados: envío de formularios, creación de pedidos, altas de clientes, sincronizaciones y notificaciones. Guarde la evidencia de la retirada, actualice el inventario y mantenga una reversión limitada, documentada y con duración definida internamente. ENISA recomienda mantener un inventario de APIs, contrastarlo con la visibilidad del perímetro y el conocimiento de desarrollo y operaciones, así como restringir el tráfico entrante a los servicios necesarios. [4]

• Confirmar propietarios técnico y de negocio.
• Avisar a consumidores internos, proveedores y responsables operativos.
• Observar, aplicar el cambio y validar procesos críticos autorizados. Documentar la baja, actualizar el inventario y conservar una reversión

Evitar que la API retirada vuelva a quedar huérfana

Los entornos no productivos requieren atención proporcional a su exposición y a los datos que procesan. Usar datos reales como atajo en pruebas puede aumentar el impacto de una API heredada si sus controles son más débiles o si queda expuesta de forma innecesaria. OWASP recomienda no utilizar datos de producción en despliegues de API no productivos; cuando no pueda evitarse, indica que deben recibir el mismo tratamiento de seguridad. [1]

Convierta el inventario en una fuente de verdad operativa. Revíselo después de cada integración nueva, migración de web, cambio de proveedor o retirada de un servicio, además de establecer una revisión periódica realista. Una auditoría de protección web puede ayudar a ordenar activos expuestos y dependencias dentro de un alcance autorizado, pero la decisión de retirar una integración debe conservar responsables de negocio y de tecnología claramente definidos.

• ¿Tiene responsable técnico y de negocio?
• ¿Se conoce qué sistemas y terceros la consumen?
• ¿Existe evidencia reciente de uso o desuso? ¿Hay una fecha de cambio comunicada y una reversión limitada?

Preguntas frecuentes

¿Cuándo se puede considerar retirada una versión antigua de una API?

Cuando existe evidencia suficiente de que no tiene consumidores activos, los responsables técnico y de negocio aprueban la baja, los procesos afectados se han verificado y el inventario refleja la retirada. La existencia de una versión nueva, por sí sola, no basta.

¿Cuánto tiempo hay que observar una API antes de retirarla?

No hay un plazo universal. Debe definirse según la frecuencia de los procesos asociados, sus ciclos operativos y la criticidad del servicio. Lo importante es que el periodo esté acordado, que se revisen fuentes de evidencia autorizadas y que se puedan identificar dependencias poco frecuentes.

¿Qué hacer si no se sabe quién usa un endpoint antiguo?

Clasifíquelo como pendiente de confirmación. Reúna datos de observación autorizados, consulte a los equipos y proveedores relacionados y evite apagarlo hasta contar con una decisión documentada. Si su exposición o los datos que trata elevan el riesgo, priorice su análisis y aplique controles defensivos proporcionales mientras se aclara su situación