Español
English
Català
Deutsch
Français
Italiano
Nederlands
Polski
Quase todas as empresas que ligam a Amazon Seller Central ao Odoo passam pelo mesmo: no primeiro mês tudo funciona bem nos testes e, passadas poucas semanas de operação com volume real, começam a surgir os mesmos sintomas. Stock que não bate certo, encomendas que se duplicam, tracking que chega tarde, a API a começar a devolver erros 429, ou um token que deixa de funcionar numa segunda-feira de manhã sem aviso prévio.
Ideia-chave: quase nenhum destes erros é um problema da Amazon nem do Odoo isoladamente. Surgem na camada de sincronização, quando o conector não respeita o modelo assíncrono da SP-API (notificações em tempo real, limites de pedidos por endpoint, tokens OAuth com validade curta) e, em vez disso, faz uma consulta simples de X em X minutos e confia que tudo chegue a tempo.
Porque falha a integração Amazon-Odoo (e nem sempre é evidente)
A SP-API da Amazon não é uma API REST simples de pedido-resposta. Combina chamadas síncronas com um sistema de notificações assíncrono (Notifications API, entregue via SQS ou EventBridge), um modelo de reports que são gerados em segundo plano e que é preciso consultar até estarem prontos, e um limite de pedidos por segundo diferente para cada operação, e não um limite global para toda a conta. A autenticação faz-se com Login With Amazon (LWA): o access token expira de hora a hora e é preciso renová-lo com o refresh_token antes de expirar.
Muitas integrações (sobretudo as montadas com automatizações genéricas do tipo Zapier, Make ou um iPaaS sem lógica específica para a Amazon) simplificam tudo isto num cron que consulta encomendas de X em X minutos e dá por assente que isso basta. Essa simplificação é a origem direta da maioria dos erros da tabela seguinte.
Tabela: sintoma, causa provável e como se evita
Oito sintomas reais que vemos repetir-se em operações que vendem na Amazon a partir do Odoo, com a causa técnica mais provável em cada caso e a solução que aplica um conector construído para operar a sério, e não apenas para passar numa demonstração.
| Sintoma | Causa provável | Como se evita |
|---|---|---|
| Stock desajustado / oversell na Amazon | Sincronização por consulta periódica de 30 a 60 minutos; a Notifications API de inventário em tempo real não é consumida | Subscrição de notificações de inventário com envio imediato após cada movimento de stock no Odoo, mais uma margem de segurança configurável |
| Encomendas duplicadas no Odoo | Reenvios do conector sem idempotência; o AmazonOrderId não é usado como chave única | Upsert idempotente indexado por AmazonOrderId, com restrição de unicidade ao nível da base de dados |
| O tracking chega tarde à Amazon (sobe o Late Shipment Rate) | O envio do tracking é feito num cron noturno por lotes, em vez de ser feito ao validar a guia de remessa | Ação automática que chama a Shipping API no instante em que a entrega é validada no Odoo |
| Erros 429 / "Request throttled" | Não se respeita o rate limit específico de cada operação da SP-API (cada endpoint tem o seu próprio bucket) | Fila de tarefas com backoff exponencial e um rate limiter próprio por endpoint, e não um global |
| Token OAuth expirado ou refresh_token inválido | Não há renovação automática do access token LWA, ou o consentimento foi revogado na Seller Central sem que ninguém desse conta | Renovação automática com margem de segurança, mais um alerta quando o refresh falha (e não quando já falha uma encomenda real) |
| Preços diferentes entre a Amazon e os restantes canais | Não há uma fonte de verdade única; o preço é editado à mão na Seller Central | O Odoo como fonte de verdade dos preços, com regras de conflito explícitas se for detetada uma edição manual na Amazon |
| Reembolsos e devoluções que não batem certo na contabilidade | Só se processam as encomendas; não se importam os relatórios de Returns/Refunds da Amazon | Importação automática dos Returns Reports para lançamentos contabilísticos de nota de crédito, e não apenas para o stock |
| Funciona nos testes, mas falha com várias contas ou marketplaces | Credenciais e estado de sincronização fixados no código para uma única conta de vendedor | Modelo de credenciais por empresa/marketplace desde o próprio modelo de dados, e não como um remendo acrescentado depois |
Checklist: o que deve ter um conector Amazon-Odoo bem construído
Antes de dar por bom um conector Amazon-Odoo (o seu ou um que esteja a avaliar comprar), reveja esta lista. Não é teoria: são os pontos exatos onde vimos falhar integrações reais.
- Consome a Notifications API da Amazon (SQS/EventBridge) em vez de depender apenas de consultas periódicas
- Importa encomendas de forma idempotente, usando o AmazonOrderId como chave única
- Envia o tracking à Amazon no momento de validar a guia de remessa, e não por lotes num cron noturno
- Aplica um rate limiter e backoff exponencial por endpoint, e não um limite global aproximado
- Renova o token OAuth (LWA) de forma automática, com alerta precoce se o refresh falhar
- Guarda um log de cada chamada à API com o código de resposta e o payload, e não apenas um genérico "sync OK"
- Suporta várias contas e marketplaces desde o próprio modelo de dados, e não como um acrescento posterior
O que fazemos na FlexigoTech: o nosso Conector Amazon para Odoo
O nosso Conector Amazon para Odoo está construído com FBA e FBM em produção real via SP-API, precisamente para não cair em nenhum dos oito pontos da tabela anterior: importação idempotente por AmazonOrderId, envio do tracking ao validar a guia de remessa e renovação automática de tokens, entre outros. Não é uma camada de automatização genérica montada sobre a API: é um módulo Odoo nativo pensado para operar com volume real, e não apenas para passar numa demonstração.
Se já tem Odoo mas o conector atual (próprio ou de terceiros) lhe está a dar algum destes sintomas, muitas vezes o problema não é trocar de conector, mas rever como está implementado dentro da sua instância. Isso costuma resolver-se no âmbito de um projeto de implementação de Odoo 19 bem feito, com a sincronização de marketplaces como parte do âmbito desde o início, e não como um remendo posterior.
Ligações úteis dentro da FlexigoTech
Perguntas frequentes
Porque se desincroniza o stock entre a Amazon e o Odoo, mesmo tendo um conector instalado?
Quase sempre porque o conector sincroniza por consulta periódica (polling) de tempos a tempos, em vez de reagir às notificações de inventário da Amazon em tempo real. Entre uma passagem e a seguinte há uma janela em que a Amazon e o Odoo não coincidem e, em catálogos com rotação elevada, isso basta para vender algo que já não tem.
Como evito encomendas duplicadas quando a Amazon reenvia a mesma notificação?
A Amazon pode reenviar a mesma notificação de encomenda mais do que uma vez; faz parte normal do seu modelo de entrega. A solução não é filtrar reenvios à mão, mas sim fazer com que o conector use o AmazonOrderId como chave única e execute um upsert idempotente: se a encomenda já existe, atualiza-a; se não existe, cria-a. Nunca insere duas vezes.
O que é um erro 429 da Amazon SP-API e como se resolve a partir do Odoo?
É um erro de throttling: ultrapassou o limite de pedidos por segundo desse endpoint concreto (cada operação da SP-API tem o seu próprio limite, e não um global). Resolve-se com uma fila de tarefas que respeita o rate limit de cada endpoint e volta a tentar com backoff exponencial, e não voltando a chamar passados poucos segundos.
O que acontece se o meu token OAuth da Amazon expirar em produção?
A Amazon usa o Login With Amazon (LWA): o access token expira de hora a hora e é preciso renová-lo com o refresh_token antes de expirar. Se o conector não automatizar essa renovação, ou se o vendedor revogou o consentimento na Seller Central sem avisar ninguém, as chamadas começam a falhar com erros de autorização até a conta ser religada à mão.
O tracking que chega tarde à Amazon afeta mesmo a minha conta?
Sim. A Amazon mede o Late Shipment Rate e, se este subir acima do seu limite, pode afetar a saúde da conta e a visibilidade dos seus listings, para além do impacto direto na experiência do comprador. Se o tracking for enviado num cron noturno em vez de no momento de validar a guia de remessa no Odoo, esse atraso é responsabilidade do conector, e não da Amazon.
O que fazemos sobre isto
Quer que revejamos a sua integração com a Amazon?
Conte-nos que sintoma tem (stock, encomendas duplicadas, tracking ou tokens) e, na primeira chamada, dizemos-lhe se é um ajuste pontual ou se o conector precisa de uma revisão de fundo. Escreva-nos para comercial@flexigobe.com ou ligue para o +34 616 809 504.