← Voltar ao blog
NetSuite SuiteTalk REST vs SOAP vs RESTlets
Integração CRM e ERP

NetSuite SuiteTalk REST vs SOAP vs RESTlets

porBruno Galo · Publicado em 16 out. 2026

Disponível emCatalàEnglishEspañolPortuguês

Alguém, um account manager ou uma linha das notas de versão, avisou que o SOAP vai desaparecer do NetSuite. Algumas das integrações correm na Celigo, outras em código SOAP antigo que ninguém assume, outras em RESTlets à medida. A Celigo acabou de acrescentar o SuiteTalk REST ao seu conector para o NetSuite. O que tem de mudar, até quando e por que ordem?

Este artigo responde com as datas da própria Oracle, cada uma marcada conforme a firmeza da fonte, e depois com uma tabela de decisão e uma checklist de migração. Factos da Oracle e da Celigo verificados a 15 de outubro de 2026. Ambos os fornecedores alteram os seus planos, por isso a checklist termina com "voltar a verificar a cada versão".

Resposta curta. Sim, convém planear a mudança. A Oracle indica que os SOAP web services serão eliminados com o NetSuite 2028.2, altura em que as integrações SOAP existentes deixam de funcionar, e que a partir da 2027.1 já não é possível criar integrações novas em SOAP nem em Token-Based Authentication (TBA). As integrações novas devem usar SuiteTalk REST com OAuth 2.0. O SuiteQL, através de REST, serve para as consultas, e os RESTlets para o que o REST não cobre. As Saved Searches não vão ser eliminadas.

  • Tem de migrar: tudo o que use SOAP web services (eliminação em 2028.2) e tudo o que use NLAuth (deixa de funcionar na 2027.1).
  • Deve migrar: as integrações com TBA para OAuth 2.0 (fim de suporte previsto, a título tentativo, para 2028.2).
  • Pode migrar quando compensar: as exportações de Saved Search, para SuiteTalk REST ou SuiteQL.

O calendário da Oracle, com datas

As versões do NetSuite são disponibilizadas conta a conta ao longo de várias semanas, por isso esta tabela dá números de versão e não datas de calendário. O estado indica a firmeza das próprias páginas da Oracle, verificadas a 15 de outubro de 2026.

Versão O que muda Estado
2025.2 Último endpoint SOAP previsto. Os seguintes apenas "se necessário" Confirmado: SOAP Removal Plans FAQ e SOAP overview da Oracle
2026.1 Oracle: todas as integrações novas devem usar REST web services com OAuth 2.0 Confirmado (uma recomendação, não um bloqueio)
2027.1 Não é possível criar integrações SOAP novas. Nem integrações TBA novas (o endpoint IssueToken e o fluxo de três passos). PKCE obrigatório nas integrações OAuth 2.0 novas com authorization code. Todas as integrações com NLAuth deixam de funcionar Confirmado: FAQ e avisos de autenticação da Oracle
2027.1 ou 2027.2 Só o último endpoint SOAP (2025.2) tem suporte; os anteriores continuam disponíveis, sem suporte Inconsistente: o SOAP overview e a página Support for Existing WSDL Versions dizem 2027.1, a FAQ diz 2027.2
Cada versão até 2028.2 O endpoint sem suporte mais antigo é desativado Confirmado: FAQ da Oracle
2028.2 O SOAP é eliminado; todas as integrações SOAP deixam de funcionar Confirmado: FAQ e SOAP overview da Oracle
2028.2 Fim de suporte do TBA Tentativo: a Oracle escreve "tentatively planned for the 2028.2 release"

Três pormenores contam na prática. As integrações existentes continuam a funcionar, e os registos de integração de integrações SOAP e TBA existentes podem ser editados até o SOAP ser totalmente eliminado. As integrações TBA existentes funcionam até ao fim de suporte definitivo do TBA. E a inconsistência entre 2027.1 e 2027.2 mantém-se hoje nas páginas da Oracle: convém planear pela data mais cedo, porque não custa nada e a mais tardia não está garantida.

As quatro vias de acesso, em linguagem simples

SuiteTalk REST web services (registos). O substituto do SOAP segundo a Oracle: JSON sobre HTTP, com criação, leitura, atualização e eliminação de registos, e OAuth 2.0 como método de autenticação preferido. Atenção: não é um clone um para um. O guia da Oracle de SOAP para REST enumera operações sem equivalente direto, entre elas changeEmail, changePassword, getDataCenterUrls, getPostingTransactionSummary e as operações de lista como updateInviteeStatusList, além de operações que exigem outra abordagem, como o SuiteQL para getDeleted.

SuiteQL, através do serviço de consultas REST. Consultas do tipo SQL sobre os dados do NetSuite, com paginação. É o substituto habitual das pesquisas SOAP e das exportações construídas como Saved Search. A Celigo afirma que a sua opção REST não necessita de licença adicional de SuiteAnalytics Connect; o acesso JDBC ou ODBC é outro canal, pelo que se deve verificar o que a conta tem licenciado.

RESTlets (SuiteScript). Um endpoint próprio, que executa SuiteScript dentro do NetSuite. Serve para lógica à medida, para vários registos numa única chamada ou para dados e comportamentos que o REST não expõe. Atenção: é código que a empresa mantém, corre sob os limites de governance do NetSuite, e tudo o que use NLAuth tem de mudar antes da 2027.1.

SOAP web services. O canal legado. Funciona nas integrações existentes até 2028.2 e não pode ser usado em desenvolvimentos novos a partir da 2027.1.

Uma nota, porque gera confusão: uma Saved Search não é uma API. É a definição de uma consulta, executada por SOAP ou por um RESTlet (na Celigo, pelo RESTlet da própria Celigo). Deixar o SOAP não significa abandonar as Saved Searches.

O que muda com a versão da Celigo de outubro de 2026

A Celigo publicou as novidades de outubro de 2026 a 6 de outubro de 2026 e atualizou-as a 7 de outubro. O que dizem, atribuído à Celigo e não medido por nós:

  • O conector do NetSuite passa a suportar SuiteTalk REST e RESTlets à medida como "first-class options" para exportações, consultas e importações baseadas em registos, sem uma ligação HTTP separada.
  • A Celigo afirma que "SuiteTalk REST is faster than Saved Search at scale" e que "requires no additional SuiteAnalytics Connect license". São afirmações do fornecedor. Não temos um benchmark próprio, e a velocidade depende do desenho da consulta, do tipo de registo e dos limites da conta.
  • A Celigo indica "Existing integrations are unchanged", ou seja, as integrações existentes não mudam.
  • O NetSuite JDBC é agora uma fonte nativa no assistente de sincronização da Celigo, para fazer joins entre tabelas do SuiteAnalytics "without the limitations of Saved Search". É relevante para cargas num data warehouse e está do lado do SuiteAnalytics Connect, pelo que o licenciamento deve ser verificado conta a conta.
  • A Celigo aloja também um servidor SFTP padrão. Só interessa se a "substituição do SOAP" for, na verdade, um projeto de troca de ficheiros.

O centro de ajuda da Celigo enumera três tipos de API para as exportações do NetSuite. Celigo RESTlets liga através do RESTlet da própria Celigo. REST APIs destina-se a fluxos baseados em registos, com o SuiteTalk por omissão e os Custom RESTlets como alternativa. SOAP Web Services serve grandes volumes, exige licença SuiteCloud Plus e é a única opção quando o bundle do integrator.io não pode ser instalado na conta. A Celigo sugere combinar exportações com Celigo RESTlets e com REST APIs para exportar mais dados por licença.

Isto significa uma via para sair dos fluxos do tipo SOAP dentro da ferramenta que já se usa, e uma alternativa às exportações de Saved Search. O que a versão não diz é como as ligações da Celigo ao NetSuite se vão autenticar quando o TBA chegar ao fim de suporte. Convém perguntar à Celigo; nós não especulamos. Para a escolha mais ampla de plataforma, ver iPaaS, ponto a ponto e middleware e Heroku Connect vs Celigo vs MuleSoft.

Tabela de decisão: que API para cada trabalho

Trabalho Melhor opção Porquê Evitar
Sincronização nova de registos (encomendas, clientes, artigos) SuiteTalk REST com OAuth 2.0 Canal recomendado pela Oracle desde a 2026.1; já de primeira classe na Celigo Desenvolvimentos SOAP novos (bloqueados a partir da 2027.1)
Leituras em massa ou incrementais para relatórios ou sincronização SuiteQL através de REST, paginado Joins e filtros; a Celigo indica que não é preciso licença de SuiteAnalytics Connect Exportações grandes de Saved Search lentas ou que excedem o tempo limite
Cargas num data warehouse SuiteQL através de REST, ou JDBC onde haja licença de SuiteAnalytics Connect Joins entre tabelas; JDBC para volume Pesquisa SOAP
Lógica complexa numa só chamada (vários registos, validações) RESTlet Executa SuiteScript no servidor Um RESTlet para um CRUD simples que o REST já cobre
Dados ou comportamentos que o REST não expõe RESTlet Cobre a lacuna Ficar no SOAP depois de 2028.2
Fluxos Celigo existentes com Celigo RESTlets ou Saved Search Manter; migrar quando o volume, a velocidade ou o acesso a registos personalizados o justifiquem Não são afetados pela eliminação do SOAP Uma reescrita de uma só vez
Fluxos Celigo existentes com o tipo de API SOAP Web Services Migrar para SuiteTalk REST antes de 2028.2 O SOAP é eliminado Deixar para 2028
Um SuiteApp ou conector de terceiros em SOAP Pedir ao fornecedor uma versão REST e uma data A dependência é dele Dar como resolvido
Qualquer coisa com NLAuth OAuth 2.0 já Deixa de funcionar na 2027.1 Esperar
Integrações com TBA Planear OAuth 2.0: client credentials entre servidores, authorization code com PKCE quando autorizam utilizadores O fim de suporte do TBA está previsto, a título tentativo, para 2028.2 Integrações TBA novas (bloqueadas a partir da 2027.1)

Não se sabe quais das integrações usam SOAP ou TBA? Fazemos o inventário em conjunto, em 30 minutos.

Como migrar de SOAP para SuiteTalk REST: 13 passos

  1. Inventário. Listar todas as integrações que tocam no NetSuite, a partir da página Manage Integrations e do registo de auditoria de acessos, e etiquetar cada uma com o tipo de API (SOAP, REST, RESTlet, Celigo RESTlet), a autenticação (NLAuth, TBA, OAuth 2.0) e um responsável.
  2. Localizar os endpoints SOAP. Anotar a versão de WSDL de cada integração. Tudo o que seja anterior a 2025.2 já passou do prazo de validade.
  3. Eliminar primeiro o NLAuth. É o limite duro da 2027.1.
  4. Verificar a Celigo, fluxo a fluxo. Ler o tipo de API de cada exportação e importação, listar os fluxos em SOAP Web Services e listar as exportações pesadas de Saved Search com os respetivos tempos de execução e erros.
  5. Perguntar aos fornecedores de apps de terceiros. Escrever a cada fornecedor de SuiteApp ou conector a pedir o plano de REST e OAuth 2.0, com data.
  6. Mapear as operações. Usar o guia da Oracle de SOAP para REST para mapear cada operação SOAP e assinalar as lacunas que exigem um RESTlet.
  7. Reescrever as pesquisas. Reescrever a lógica das pesquisas SOAP e das Saved Searches como SuiteQL, e reconciliar o número de linhas e os totais com o resultado anterior antes de mudar.
  8. Configurar a autenticação. Criar registos de integração OAuth 2.0, com client credentials entre servidores e authorization code com PKCE quando autorizam utilizadores. Rodar os segredos e usar perfis de privilégio mínimo.
  9. Verificar concorrência e governance. Consultar os limites de concorrência da conta e agendar as cargas pesadas em conformidade.
  10. Testar na sandbox. Executar o antigo e o novo em paralelo, comparar os resultados e aproveitar as janelas de release preview.
  11. Mudar fluxo a fluxo. Manter uma via de regresso e atualizar a monitorização e os alertas.
  12. Desativar o antigo. Desativar os registos de integração e os tokens antigos, e documentar o novo tipo de API e o seu responsável.
  13. Voltar a verificar a cada versão. A Oracle pode ajustar as datas; ler as notas de versão em cada .1 e .2.

Armadilhas habituais

  • O REST não é um clone do SOAP. O comportamento de listas e lotes é diferente, faltam algumas operações e os formatos de erro são outros.
  • Os totais nem sempre coincidem. Um resultado de SuiteQL pode diferir da Saved Search que substitui. Convém reconciliar antes da mudança, sobretudo com dados multimoeda; o nosso artigo sobre um plano de contas único em várias subsidiárias mostra onde essas diferenças se escondem.
  • Testar com o perfil da integração, não com Administrator. Uma integração que funciona com um administrador pode falhar com o perfil real.
  • Deixar para 2028. Os ciclos de release preview e de atualização da sandbox encurtam a janela real. A nossa nota sobre porque atrasam as implementações NetSuite vale também para as migrações.
  • Programar um RESTlet por reflexo. O código à medida tem de ser mantido pela empresa; padrão versus customização é o critério a aplicar.

Onde se encaixa a Atypical Tech

Somos engenheiros de integração de NetSuite sediados em Espanha, parceiro de implementação da Celigo e parceiro da Stacksync. Construímos APIs e RESTlets à medida onde o REST não chega, e migramos fluxos Celigo ou SOAP à medida para SuiteTalk REST e SuiteQL. Não somos parceiro da Oracle NetSuite nem nos apresentamos como tal. Se o objetivo final for uma sincronização bidirecional e não uma reescrita, a Stacksync é uma opção; para sincronizar com um data warehouse, ver CDC gerido versus Debezium self-hosted.

Perguntas frequentes

O SOAP do NetSuite vai ser descontinuado?

Sim. A 15 de outubro de 2026, a Oracle indica que os SOAP web services serão eliminados com o NetSuite 2028.2, altura em que as integrações SOAP existentes deixam de funcionar. O 2025.2 é o último endpoint SOAP previsto e, a partir da 2027.1, não é possível criar integrações SOAP novas.

Quando deixam de funcionar as integrações SOAP do NetSuite?

Com a versão 2028.2, segundo a Oracle. Antes disso, a cada versão é desativado o endpoint sem suporte mais antigo, pelo que integrações em versões antigas de WSDL podem falhar mais cedo. Convém migrar para SuiteTalk REST com margem em relação a 2028.2.

O NetSuite exige OAuth 2.0?

Nas integrações novas, a partir da 2027.1: a Oracle indica que as integrações novas não poderão usar TBA e que as novas com authorization code precisam de PKCE. As integrações TBA existentes continuam a funcionar até ao fim de suporte definitivo do TBA, previsto a título tentativo para 2028.2. A Oracle recomenda abandonar o NLAuth, que deixa de funcionar na 2027.1.

Qual é a diferença entre SuiteTalk REST e um RESTlet?

O SuiteTalk REST é a API padrão da Oracle para registos e consultas SuiteQL. Um RESTlet é um endpoint próprio de SuiteScript dentro do NetSuite. Usa-se o REST por omissão e um RESTlet para lógica à medida ou para o que o REST não cobre.

O que é o SuiteQL?

Uma linguagem de consulta do tipo SQL para os dados do NetSuite. Através do SuiteTalk REST, permite a uma integração executar consultas paginadas com joins e filtros. É o substituto habitual das pesquisas SOAP e das exportações de Saved Search.

É preciso SuiteAnalytics Connect para usar SuiteQL?

A Celigo afirma que a sua opção SuiteTalk REST não requer licença adicional de SuiteAnalytics Connect. O acesso JDBC e ODBC, incluindo a fonte de sincronização JDBC da Celigo, está do lado do SuiteAnalytics Connect. Convém verificar a licença da própria conta junto da NetSuite.

As minhas integrações Celigo com o NetSuite têm de mudar?

Não de imediato: a Celigo indica que as integrações existentes não mudam com a versão de outubro de 2026. Os fluxos com o tipo de API SOAP Web Services têm de migrar antes de 2028.2. Os fluxos com Celigo RESTlets ou Saved Search podem passar para SuiteTalk REST quando a velocidade ou o acesso o justificarem.

A Celigo afirma-o "at scale" nas novidades da versão de outubro de 2026. Nós não o medimos. A velocidade depende do desenho da consulta, do tipo de registo e dos limites da conta, pelo que convém testar as exportações mais pesadas em paralelo antes de mudar.

Posso continuar a usar Saved Searches?

Sim. As Saved Searches não vão ser eliminadas; o que vai ser eliminado são os SOAP web services. Podem ser executadas através de um RESTlet, como faz o RESTlet da própria Celigo, em vez de SOAP, ou as mais pesadas podem ser reescritas como SuiteQL.

Quem pode migrar integrações SOAP do NetSuite na Europa?

A Atypical Tech: engenheiros de integração sediados em Espanha e parceiro de implementação da Celigo e da Stacksync, que constroem integrações com SuiteTalk REST, SuiteQL e RESTlets para empresas mid-market.

Fontes

Todas verificadas a 15 de outubro de 2026.

Peça a revisão da sua integração com o NetSuite

Trinta minutos costumam bastar para mapear o que tem de migrar antes da 2027.1 e da 2028.2, e o que pode ficar. Marque uma chamada ou consulte as nossas integrações; quem usa a Celigo pode começar pela nossa página da Celigo.

Comentários

Ainda não há comentários.

Deixe um comentário

Seu comentário será revisado antes da publicação.

An unhandled error has occurred. Reload 🗙