A documentação principal do Odoo informa que o serviço RPC legado de banco de dados é removido no Odoo 20. As APIs XML-RPC e JSON-RPC mais amplas estão descontinuadas desde a versão 19.0, mas o Odoo 20 não remove todos os serviços legados. O Odoo documenta que os serviços common e object permanecem disponíveis até o Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) As equipes de integração, portanto, precisam identificar o serviço usado por cada conexão externa, em vez de tratar o suporte RPC legado como um único recurso com uma única data de remoção.
A página do evento das Américas do Odoo informou que o Odoo 20 seria lançado durante o evento em San Francisco, em 2 e 3 de setembro de 2026. (Oxp26 Americas Introduction) O planejamento de atualização já pode considerar a remoção documentada do serviço de banco de dados, mas as decisões de produção devem ser verificadas na documentação final de lançamento do Odoo 20.
A remoção se aplica a um serviço específico
Odoo identifica `/xmlrpc`, `/xmlrpc/2` e `/jsonrpc` como endpoints legados descontinuados a partir da versão 19.0. Dentro dessas APIs, o serviço de banco de dados é removido no Odoo 20, enquanto os serviços common e object estão programados para permanecer até o Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Uma integração que use um serviço mantido pode continuar operando após uma atualização para o Odoo 20, mas o endpoint por si só não estabelece compatibilidade.
Um sistema pode usar serviços diferentes por meio da interface RPC legada. Uma revisão de integração deve, portanto, registrar tanto o endpoint quanto o serviço chamado. Descrever uma aplicação apenas como uma integração XML-RPC ou JSON-RPC não mostra se ela depende de uma operação removida no Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
A disponibilidade contínua dos serviços common e object é temporária. Odoo programa a remoção de ambos no Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) As equipes podem separar o trabalho urgente nas chamadas do serviço de banco de dados da migração dos serviços mantidos, mas ambos exigem um plano.
JSON-2 muda o contrato da requisição
Odoo documenta JSON-2 como a API de substituição. O formato do endpoint é `/json/2/<model>/<method>`, com o model e o method incluídos na URL. (Odoo master Docs: Reference External API) A migração, portanto, envolve mais do que substituir o caminho base em um cliente RPC existente. Cada operação deve ser mapeada para a rota adequada de model e method.
JSON-2 exige argumentos nomeados em um corpo de requisição JSON, em vez de argumentos posicionais de RPC. (Odoo master Docs: Reference External API) Wrappers, middleware e clientes gerados existentes podem assumir que a ordem dos argumentos define o significado. Esses componentes precisam de revisão individual. Redirecionar uma requisição legada para o novo endpoint não funcionará se o cliente continuar construindo parâmetros posicionais.
Para cada operação migrada, as equipes devem documentar o model de destino, o method e os argumentos nomeados exigidos pelo JSON-2. (Odoo master Docs: Reference External API) As requisições devem então ser testadas no ambiente relevante do Odoo 20, especialmente quando uma biblioteca de integração compartilhada constrói chamadas para vários aplicativos. Comparações estáticas de payload não confirmam como o servidor ou o cliente lida com a requisição completa.
A autenticação também deve mudar
JSON-2 usa autenticação por API key bearer. (Odoo master Docs: Reference External API) O trabalho de migração deve abranger a criação de chaves, o armazenamento seguro, o tratamento do cabeçalho de autorização e a substituição de chaves. Proxies, gateways e bibliotecas de cliente devem ser verificados para garantir que preservem o cabeçalho ao encaminhar requisições. O registro, o monitoramento e o tratamento de erros também devem ser revisados para que as credenciais não sejam expostas.
A documentação estabelece o método de autenticação, mas cada organização deve determinar como as chaves de API se encaixam em seus controles de credenciais. (Odoo master Docs: Reference External API) Isso inclui atribuir responsabilidade pelas chaves, controlar onde elas podem ser usadas e definir como as integrações afetadas serão atualizadas quando uma chave for substituída.
Campos binários têm uma mudança de compatibilidade separada
O changelog da ORM do Odoo registra outra mudança de RPC no Odoo 20: a representação de campos binários adiciona `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Isso é अलग? no separate? Need Portuguese. This is separate from the database-service removal because it changes returned data rather than service availability. Applications that read, transform or validate responses containing binary fields should be included in compatibility testing.
O changelog confirma que o membro `filename` foi adicionado, mas seu efeito prático depende do cliente. (Odoo master Docs: Orm Changelog) Os testes devem verificar se esquemas rígidos, serializadores, comparações de resposta e transformações downstream aceitam o membro adicional. Clientes que ignoram campos desconhecidos podem não exigir ajuste, mas esse comportamento deve ser verificado, e não presumido.
Como delimitar a auditoria de integração
Comece identificando conexões que usam `/xmlrpc`, `/xmlrpc/2` ou `/jsonrpc`, que o Odoo classifica como endpoints descontinuados. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) O inventário deve abranger aplicações desenvolvidas internamente, middleware, processos agendados e conectores de terceiros, quando a configuração ou o código-fonte estiver disponível. Atribua um responsável a cada conexão para que sua finalidade e seu status possam ser verificados.
Em seguida, classifique cada conexão por serviço legado. O uso do serviço de banco de dados requer correção para o Odoo 20, enquanto o uso dos serviços common e object continua documentado como disponível até o Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Isso dá suporte a um plano em fases: trate primeiro a incompatibilidade do Odoo 20 e, depois, defina datas de migração para as demais chamadas descontinuadas.
Para integrações que estão migrando para JSON-2, registre a rota `/json/2/<model>/<method>`, os argumentos nomeados da requisição e a autenticação por chave de API bearer exigida pela interface de substituição. (Odoo master Docs: Reference External API) Os casos de teste devem cobrir requisições bem-sucedidas, autenticação rejeitada, argumentos nomeados inválidos e o tratamento dos dados retornados pela aplicação. Adicione casos de campo binário sempre que esses campos ocorrerem.
Confirme o comportamento final do Odoo 20
Os detalhes da remoção são extraídos da documentação de desenvolvimento master do Odoo, enquanto a data de lançamento anunciada vem de uma página do evento que informa que o Odoo 20 seria lançado durante o evento das Américas de setembro de 2026. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Antes da implantação, as equipes devem revisar novamente a documentação da versão lançada do Odoo 20 e a edição exata e o build que pretendem usar.
Usar um endpoint RPC descontinuado não prova, por si só, que uma integração deixará de funcionar no Odoo 20, porque os serviços common e object continuam documentados até o Odoo 22. Da mesma forma, o funcionamento bem-sucedido em uma versão anterior não estabelece compatibilidade para uma chamada ao serviço de banco de dados após sua remoção. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Checklist de decisão de upgrade
Antes de aprovar uma atualização para o Odoo 20, os responsáveis pela decisão devem solicitar um registro de integrações mostrando cada endpoint descontinuado, o serviço chamado, seu responsável e a correção planejada. Dependências do serviço de banco de dados devem ter uma substituição testada. Integrações que permanecerem nos serviços common ou object devem ter uma data de migração separada, refletindo sua remoção documentada no Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
A revisão deve confirmar que as implementações JSON-2 colocam o modelo e o método na URL, usam argumentos JSON nomeados e autenticam com uma chave de API bearer. Quando houver campos binários, os testes devem considerar a adição de `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Estas verificações distinguem a remoção imediata do serviço de banco de dados do Odoo 20 da desativação posterior dos demais serviços legados.