Español
English
Català
Deutsch
Français
Italiano
Nederlands
Polski
«A Temu tem API?» Sim. A pergunta útil é outra: o que é preciso pedir para a usar, o que se pode ler, o que se pode escrever e o que acontece quando responde que não. Estas quatro respostas decidem se a integração aguenta um pico de encomendas ou se cai na primeira sexta-feira de saldos. Vamos por ordem.
As credenciais não são um utilizador e uma palavra-passe
A Temu funciona como qualquer marketplace sério: há uma aplicação registada, com a sua chave e o seu segredo, e há uma autorização que a loja concede a essa aplicação. Daí sai um token que caduca, e a integração tem de saber quando e avisar com margem para renovar a autorização antes de expirar. No Odoo, isso significa que o token vive num parâmetro do sistema com permissões, e não num campo de texto que alguém colou uma vez e de que ninguém se lembra. E significa que, no dia em que a loja revoga a autorização, a sincronização tem de parar e avisar, e não continuar a falhar em silêncio durante uma semana.
As credenciais são sempre do vendedor. Não revendemos acesso nem partilhamos uma aplicação entre clientes: se amanhã deixar de trabalhar connosco, a ligação continua a ser sua e não há nada a devolver.
Que famílias de endpoints são mesmo necessárias
Os nomes exatos mudam entre versões da API; as famílias não, e são cinco. Listagem de encomendas por janela temporal, para trazer o que é novo sem pedir o histórico inteiro. Detalhe da encomenda, que é onde vêm as linhas, a variante, os valores e os impostos. Confirmação de envio, com transportadora e número de seguimento, que é a única coisa que a Temu analisa para o dar por cumprido. Catálogo, para publicar e atualizar fichas. E stock, que fica à parte do catálogo porque muda mil vezes mais. Se uma integração só cobre as duas primeiras, não é uma integração: é um importador.
O detalhe de cada família está desenvolvido nos dois artigos irmãos: importar as encomendas sem perder dados e sincronizar produtos e preços.
O stock é a chamada que mais se repete
Uma loja com 2 000 referências que reenvia todo o stock de quinze em quinze minutos faz 192 000 escritas por dia para alterar, com sorte, duzentos valores. Isso não é sincronizar: é gastar quota. O correto é enviar apenas o que mudou desde o último envio, agrupado em lotes, e disparar também uma atualização imediata quando uma venda deixa uma referência à beira de zero. A frequência alta não evita a sobrevenda; a margem de segurança evita.
Limites: a API não é uma base de dados que se possa consultar à vontade
Toda a API de marketplace tem um teto de chamadas por janela de tempo, e mais cedo ou mais tarde chega lá. O que separa uma integração saudável de uma avariada é o que faz quando lá chega. Uma recusa por excesso de chamadas não é um erro que se engole e se esquece: é uma ordem para esperar. A integração deve tentar de novo com espera crescente, pôr em fila o que não coube e retomá-lo no ciclo seguinte sem duplicar nada. Tudo isto vive numa fila de tarefas, e não num ciclo dentro do cron. Quando essa fila encrava, o sintoma é o que contamos em filas bloqueadas no Odoo.
Registar cada chamada não é paranoia: é a única prova
Quando uma encomenda não aparece, ou a Temu diz que não recebeu o número de seguimento, a discussão ganha-se com o registo ou não se ganha. É preciso guardar, por chamada: o momento exato, o endpoint, o corpo enviado, o código e a resposta recebida, e o identificador da encomenda ou a referência afetada. Sem segredos nem tokens em claro, e com uma validade razoável para que a tabela não consuma o disco. É a primeira coisa que vemos ao auditar um conector feito por outra pessoa, e a sua ausência é a causa de metade dos casos impossíveis de diagnosticar, como os que descrevemos em erros frequentes contra uma API de marketplace.
O que faz o nosso conector (e o que não faz)
O conector da Temu para Odoo cobre as cinco famílias: importa as encomendas por janela temporal, confirma os envios com transportadora e número de seguimento, publica produtos e SKU e envia o stock por SKU, agrupado por artigo. A loja é autorizada com o código que a Temu emite, e o conector guarda quando o token caduca e mostra se a ligação continua ativa. Sincroniza por cron e por webhook, guarda o pedido e a resposta de cada confirmação de envio e o conteúdo de cada webhook recebido, e, se a Temu subir de versão um método, repete a chamada com a nova versão.
O que hoje não faz, dito sem rodeios: não envia só o stock que mudou, porque em cada passagem manda o de todas as referências associadas; não tem uma fila de tarefas com espera crescente e não regista todas as chamadas. Uma recusa por limite fica no log do servidor e é repetida na passagem seguinte do cron. Funciona no Odoo 17, 18 e 19. Se o que está a decidir é se lhe convém isto ou um middleware por cima, está comparado em middleware ou conector nativo: há casos em que a resposta certa não somos nós.
Perguntas frequentes
É preciso uma conta de programador na Temu?
É preciso que a sua loja autorize a aplicação a partir do seu painel de vendedor. As credenciais que saem daí são suas e o conector usa-as; nós não revendemos acesso.
Pode testar-se sem pôr em risco a loja real?
Sim: levanta-se uma base de dados de testes do Odoo com as credenciais reais e ativam-se apenas as leituras. Ler encomendas e catálogo não altera nada na Temu; o que deve ficar desligado até validar é a publicação de fichas, o stock e a confirmação de envio.
De quanto em quanto tempo convém chamar a API?
Não há um número igual para todos. Encomendas, a cada poucos minutos, porque o prazo de envio está a correr. Stock, por alteração e não por relógio. Catálogo, só quando a ficha muda a sério. Chamar com mais frequência do que os dados mudam só gasta quota.
Ligações úteis dentro da FlexigoTech
O que fazemos sobre isto
Vai atacar a API da Temu por conta própria?
Diga-nos quantas referências movimenta, em que países vende e quem prepara os envios. Dizemos-lhe que famílias de endpoints precisa e onde vai esbarrar nos limites. Escreva para comercial@flexigobe.com ou marque uma chamada.