La documentación principal de Odoo indica que el servicio RPC heredado de base de datos se elimina en Odoo 20. Las APIs XML-RPC y JSON-RPC más amplias están obsoletas desde la versión 19.0, pero Odoo 20 no elimina todos los servicios heredados. Odoo documenta que los servicios common y object seguirán disponibles hasta Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Por tanto, los equipos de integración deben identificar el servicio que usa cada conexión externa, en lugar de tratar la compatibilidad RPC heredada como una sola función con una única fecha de retirada.
La página del evento de Odoo para América indicaba que Odoo 20 se lanzaría durante su evento de San Francisco los días 2 y 3 de septiembre de 2026. (Oxp26 Americas Introduction) La planificación de la actualización puede tener en cuenta ahora la eliminación documentada del servicio de base de datos, pero las decisiones de producción deben verificarse con la documentación final de la versión 20 de Odoo.
La eliminación afecta a un servicio concreto
Odoo identifica `/xmlrpc`, `/xmlrpc/2` y `/jsonrpc` como endpoints heredados obsoletos desde la versión 19.0. Dentro de esas APIs, el servicio de base de datos se elimina en Odoo 20, mientras que los servicios common y object seguirán hasta Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Una integración que use un servicio mantenido puede seguir funcionando tras una actualización a Odoo 20, pero el endpoint por sí solo no confirma la compatibilidad.
Un sistema puede usar distintos servicios a través de la interfaz RPC heredada. Por ello, una revisión de integración debe registrar tanto el endpoint como el servicio llamado. Describir una aplicación solo como una integración XML-RPC o JSON-RPC no muestra si depende de una operación eliminada en Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
La disponibilidad continuada de los servicios common y object es temporal. Odoo tiene previsto eliminarlos en Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Los equipos pueden separar el trabajo urgente sobre llamadas al servicio de base de datos de la migración de los servicios mantenidos, pero ambos requieren un plan.
JSON-2 cambia el contrato de la solicitud
Odoo documenta JSON-2 como la API de sustitución. Su formato de endpoint es `/json/2/<model>/<method>`, con el modelo y el método incluidos en la URL. (Odoo master Docs: Reference External API) Por tanto, la migración implica algo más que sustituir la ruta base en un cliente RPC existente. Cada operación debe asignarse a la ruta adecuada de modelo y método.
JSON-2 requiere argumentos con nombre en el cuerpo JSON de la solicitud, en lugar de argumentos posicionales RPC. (Odoo master Docs: Reference External API) Los wrappers, middleware y clientes generados existentes pueden asumir que el orden de los argumentos determina el significado. Esos componentes deben revisarse por separado. Redirigir una solicitud heredada al nuevo endpoint no funcionará si el cliente sigue construyendo parámetros posicionales.
Para cada operación migrada, los equipos deben documentar el modelo de destino, el método y los argumentos con nombre que requiere JSON-2. (Odoo master Docs: Reference External API) Después, las solicitudes deben probarse en el entorno correspondiente de Odoo 20, especialmente cuando una biblioteca de integración compartida construye llamadas para varias aplicaciones. Las comparaciones estáticas de cargas útiles no pueden confirmar cómo el servidor o el cliente gestionan la solicitud completa.
La autenticación también debe cambiar
JSON-2 usa autenticación por clave API bearer. (Odoo master Docs: Reference External API) El trabajo de migración debe abarcar la creación de claves, el almacenamiento seguro, el manejo del encabezado de autorización y el reemplazo de claves. Los proxies, gateways y bibliotecas cliente deben revisarse para asegurar que conserven el encabezado al reenviar solicitudes. También deben revisarse el registro, la supervisión y el manejo de errores para que no se expongan credenciales.
La documentación establece el método de autenticación, pero cada organización debe determinar cómo encajan las claves API en sus controles de credenciales. (Odoo master Docs: Reference External API) Eso incluye asignar la responsabilidad de las claves, controlar dónde pueden usarse y definir cómo se actualizarán las integraciones afectadas cuando se reemplace una clave.
Los campos binarios tienen un cambio de compatibilidad aparte
El registro de cambios del ORM de Odoo recoge otro cambio RPC de Odoo 20: la representación de los campos binarios añade `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Esto es independiente de la eliminación del servicio de base de datos porque cambia los datos devueltos en lugar de la disponibilidad del servicio. Las aplicaciones que leen, transforman o validan respuestas que contienen campos binarios deben incluirse en las pruebas de compatibilidad.
El registro de cambios confirma que se añade el miembro `filename`, pero su efecto práctico depende del cliente. (Odoo master Docs: Orm Changelog) Las pruebas deben comprobar si los esquemas estrictos, los serializadores, las comparaciones de respuestas y las transformaciones posteriores aceptan el miembro adicional. Es posible que los clientes que ignoran los campos desconocidos no requieran ajustes, pero ese comportamiento debe verificarse y no darse por supuesto.
Cómo delimitar la auditoría de integración
Empiece por identificar las conexiones que usan `/xmlrpc`, `/xmlrpc/2` o `/jsonrpc`, que Odoo marca como endpoints obsoletos. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) El inventario debe cubrir aplicaciones desarrolladas internamente, middleware, procesos programados y conectores de terceros cuando la configuración o el código fuente estén disponibles. Asigne un propietario a cada conexión para que se pueda verificar su propósito y estado.
A continuación, clasifique cada conexión por servicio heredado. El uso del servicio de base de datos requiere remediación para Odoo 20, mientras que el uso de los servicios common y object sigue documentado como disponible hasta Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Esto respalda un plan por fases: abordar primero la incompatibilidad de Odoo 20 y luego fijar fechas de migración para el resto de las llamadas obsoletas.
Para las integraciones que migran a JSON-2, registre la ruta `/json/2/<model>/<method>`, los argumentos de solicitud con nombre y la autenticación con API-key bearer que requiere la interfaz de reemplazo. (Odoo master Docs: Reference External API) Los casos de prueba deben cubrir solicitudes correctas, autenticación rechazada, argumentos con nombre no válidos y el manejo por la aplicación de los datos devueltos. Añada casos de campos binarios siempre que aparezcan esos campos.
Confirme el comportamiento final de Odoo 20
Los detalles de la eliminación se extraen de la documentación para desarrolladores de master de Odoo, mientras que el momento anunciado del lanzamiento procede de una página del evento que indica que Odoo 20 se lanzaría durante el evento Americas de septiembre de 2026. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Antes de la implementación, los equipos deben volver a comprobar la documentación de la versión publicada de Odoo 20 y la edición y compilación exactas que tienen previsto usar.
Usar un endpoint RPC obsoleto no demuestra por sí solo que una integración vaya a dejar de funcionar en Odoo 20, porque los servicios common y object siguen documentados hasta Odoo 22. A la inversa, que funcione en una versión anterior no garantiza la compatibilidad de una llamada al servicio de base de datos después de su eliminación. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Lista de verificación para la decisión de actualización
Antes de aprobar una actualización a Odoo 20, los responsables de la decisión deben solicitar un registro de integraciones que muestre cada endpoint obsoleto, el servicio llamado, su propietario y la remediación planificada. Las dependencias del servicio de base de datos deben contar con un reemplazo probado. Las integraciones que permanezcan en los servicios common o object deben tener una fecha de migración separada que refleje su eliminación documentada en Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Referencia de la API RPC externa)
La revisión debe confirmar que las implementaciones JSON-2 colocan el modelo y el método en la URL, usan argumentos JSON con nombre y se autentican con una clave API bearer. Cuando haya campos binarios, las pruebas deben tener en cuenta la adición de `BinaryValue.filename`. (Odoo master Docs: Referencia de la API externa; Odoo master Docs: Registro de cambios de ORM) Estas comprobaciones distinguen la eliminación inmediata del servicio de base de datos de Odoo 20 de la retirada posterior de los demás servicios heredados.