Em poucas linhas: o tlppCore traz um servidor REST que roda dentro do próprio AppServer do Protheus. As rotas são declaradas com annotations no código, a documentação sai no padrão OpenAPI, há autenticação Basic e oAuth2 e parte da configuração pode ser ajustada sem parar o serviço. Em julho de 2026, a TOTVS atualizou o Gerador de Documentação para APIs REST em TLPP. Para o negócio, o ganho é integrar mais rápido, com menos retrabalho e mais controle.
Portal de clientes, aplicativo de vendedores, CRM, e-commerce, integração com montadora no DMS: quase toda conversa entre o Protheus e outro sistema hoje passa por uma API REST. A pergunta para a gestão não é técnica. É quanto tempo leva para colocar uma integração no ar, quanto custa mantê-la e quão rápido se descobre o que deu errado quando ela falha.
Por que integração virou assunto de negócio?
Cada integração mal documentada vira dependência de uma pessoa. Cada serviço que precisa ser reiniciado para um ajuste vira janela de indisponibilidade. E cada erro sem log claro vira horas de investigação, normalmente no pior momento, como o fechamento do mês ou o pico de vendas.
O REST do TLPP ataca justamente esses pontos, segundo a documentação do TDN.
O que o REST do TLPP muda na prática?
| Recurso documentado pela TOTVS | Em termos simples | Valor para o negócio |
|---|---|---|
| Servidor nativo no AppServer | A API roda no próprio servidor do Protheus | Menos peças para manter e ganho de desempenho e estabilidade |
| Annotations | A rota fica escrita junto da função | Código mais simples e fácil de revisar |
| Serviços dinâmicos | Rotas podem ser criadas em tempo de execução | Flexibilidade para novos parceiros |
| OpenAPI nativo | O servidor publica a própria documentação | Parceiro integra sem depender de manual à parte |
| Ajuste de logs em tempo real | Mudar nível de log sem reiniciar | Diagnóstico sem parar a operação |
| Hooks e trace de tempo | Pontos para tratar erros e medir cada etapa | Problema encontrado mais rápido |
Como nasce uma API em TLPP?
O exemplo do TDN é curto de propósito. Com os includes tlpp-core.th e tlpp-rest.th, que já vêm no tlpp.rpo padrão, basta escrever a annotation acima da função ou do método, como @Get, @Post, @Put, @Delete ou @Patch, com a rota desejada. A resposta é devolvida pelo objeto oRest. Dá para escrever o serviço como função, para casos simples, ou como classe, quando há mais regras a organizar.
Para a empresa, isso significa que uma API nova não exige uma camada extra de software nem um projeto de infraestrutura à parte. O esforço fica concentrado na regra de negócio.
Como fica a segurança?
O servidor REST do TLPP permite ativar autenticação nas requisições, com os esquemas Basic e oAuth2. No oAuth2, disponível a partir da versão 19.3.1, a TOTVS implementou o modelo em que cliente e aplicação geram tokens de acesso e de renovação no formato Bearer, sem que o servidor guarde a senha do usuário.
Há ainda uma regra que vale desde a 12.1.2510: em serviços REST, empresa e filial são definidas pelo header tenantId, e o código não pode mais trocar o contexto atribuindo valor a cEmpAnt ou __cUserId. Integrações antigas que faziam isso precisam ser revistas antes da atualização.
A documentação deixa de ser um documento à parte?
Em boa parte, sim. O servidor gera a documentação no formato OpenAPI, e os metadados das annotations, como título, descrição, parâmetros e respostas, alimentam essa documentação. O Gerador de Documentação do tlppCore, com página atualizada em 31/07/2026, padroniza esse processo, e a TOTVS mantém um repositório público de exemplos.
O TDN faz um alerta importante: hoje, só o metadado de endpoint define comportamento no servidor. Marcar um parâmetro como obrigatório na documentação não substitui a validação no código. Documentar bem não dispensa testar bem.
Como operar sem parar o serviço?
A API de configuração em tempo real permite mudar os parâmetros de log do REST Server, como nível de detalhe, impressão de erro e contagem de tempo, sem reiniciar o serviço nem o servidor. Os hooks permitem tratar a criação de threads, a escolha do pool, os erros e a resposta final. O trace de tempo mostra quanto cada camada consumiu no atendimento.
Na prática, quando uma integração fica lenta, a equipe aumenta o log, encontra o gargalo e volta ao normal, sem janela de manutenção.
Lista de verificação para novas APIs
- Mapear as integrações atuais e quais dependem de pessoas ou de documentação manual.
- Definir o padrão de autenticação, Basic ou oAuth2, por tipo de parceiro.
- Padronizar o uso do header tenantId para empresa e filial.
- Escrever as rotas com annotations e metadados completos.
- Validar no código todos os parâmetros obrigatórios.
- Publicar a documentação OpenAPI para quem vai consumir a API.
- Combinar com a TI os níveis de log e o uso do trace de tempo.
- Revisar integrações antigas que alteram cEmpAnt ou __cUserId.
Perguntas frequentes
Preciso instalar algo além do Protheus?
Segundo o TDN, os includes necessários já estão no tlpp.rpo padrão, e o serviço roda no AppServer, depois de configurado via INI ou JSON.
A documentação OpenAPI valida os dados recebidos?
Não. Ela descreve o contrato. A validação continua sendo responsabilidade do código.
Dá para ajustar o REST sem parar a operação?
Os parâmetros de log, sim, pela API de configuração em tempo real.
Para levar desta leitura
- O REST do TLPP roda no próprio AppServer, com rotas declaradas por annotations.
- A documentação OpenAPI nasce do código e reduz a dependência de manuais.
- Basic, oAuth2 e o header tenantId formam a base de segurança das integrações.
- Logs ajustáveis em tempo real e trace de tempo encurtam o diagnóstico.
Como a WIP Solutions pode ajudar
Uma boa API é aquela que o parceiro consegue usar sem ligar para ninguém e que a TI consegue diagnosticar sem parar a empresa. A WIP Solutions, Prestador de Serviços Homologado TOTVS, apoia empresas que usam o Protheus no Backoffice e no DMS a desenhar, documentar e revisar integrações REST em TLPP. Se você quer organizar suas integrações, fale com nosso time.