Conector Amazon para Odoo: qué credenciales pide SP-API, qué límites de tasa tiene y qué debe cubrir

Si buscas conector Amazon Odoo o Amazon SP-API Odoo, la respuesta corta es esta: hacen falta tres credenciales que no las da el mismo sitio —una aplicación SP-API registrada por un perfil de desarrollador con los roles aprobados, unas claves LWA de esa aplicación y un refresh token por cada vendedor que la autoriza—, más el marketplace id y el endpoint regional. Y una decisión de diseño: los límites son cubos de fichas por operación, así que el conector lleva cola y backoff, no bucles.

Todo lo que sigue está comprobado el 13 de septiembre de 2026 en la documentación oficial de SP-API y en el código de nuestro Conector Amazon Seller para Odoo, publicado en las ramas 19.0, 18.0 y 17.0, con 786 pruebas propias en la de Odoo 19 y 685 en cada una de las otras dos.

Qué debe resolver un conector Amazon Odoo

• Importación fiable de pedidos y reservas de stock.
• Mapeo de SKU, variantes y listings sin duplicados.
• Sincronización de estados, tracking y confirmaciones.
• Gestión de precios, incidencias y casos de error.
• Tratamiento de FBA cuando forma parte de la operativa.
• Logs y reintentos cuando falla Amazon o la cola interna.

Cada línea entra por una puerta distinta —/orders/v0, /listings/2021-08-01, /feeds/2021-06-30, /reports/2021-06-30— y cada puerta tiene su propio límite.

Qué credenciales pide SP-API y quién las da

1. La aplicación. SP-API no se abre con el usuario de Seller Central, sino con una aplicación registrada en el Solution Provider Portal por un perfil de desarrollador aprobado. Al registrarla se eligen roles —Amazon documenta dieciocho— y solo puedes elegir los ya aprobados. Cuatro son restringidos por tocar datos personales, entre ellos Direct-to-Consumer Shipping. Y tener el rol no basta: la dirección de entrega se pide con un restricted data token (POST /tokens/2021-03-01/restrictedDataToken).

2. Las claves LWA. De la aplicación salen un client_id y un client_secret de Login with Amazon. El secreto caduca a los 180 días: Amazon avisa 90 días antes y el viejo aguanta siete días más. Pasado el plazo las llamadas fallan sin que nadie haya tocado nada, y el síntoma —invalid_client de madrugada— no se parece a su causa; por eso el conector guarda esa fecha y avisa con un cron diario.

3. El refresh token del vendedor. Es lo único que no rellenas tú: lo genera el vendedor autorizando la app en sellercentral…/apps/authorize/consent, con el application_id y un state propio; si la app sigue en borrador se añade &version=beta, y al publicarla hay que quitarlo. Amazon lo devuelve a tu redirect URI con un spapi_oauth_code que se canjea en menos de cinco minutos en https://api.amazon.com/auth/o2/token: de ahí salen un access_token, que caduca a la hora, y el refresh_token.

4. Marketplace y región. Una cuenta no es un país: es un marketplace id (España A1RKKUPIHCS9HS, Francia A13V1IB3VIYZZH) apuntando a un endpoint regional, https://sellingpartnerapi-eu.amazon.com en Europa. Nuestro conector trae los 23 marketplaces como datos y cada cuenta apunta a uno solo, para que stock, impuestos y canal salgan del sitio correcto.

Límites de tasa: por qué el conector necesita cola

Amazon reparte el tráfico con un cubo de fichas: cada operación tiene una tasa (fichas por segundo) y un burst (capacidad), y cada petición gasta una ficha. Cuando el cubo se vacía llega un 429, que la documentación llama reintentable, y —cuando está disponible, que no siempre— vuelve la cabecera x-amzn-RateLimit-Limit con el límite de tu par vendedor-aplicación. Los límites son por operación, y los de la tabla son los valores por defecto, que Amazon puede subir a quien mueve más volumen.

Esa tabla explica el diseño. Como getOrders va a un minuto, los pedidos se leen con marca de agua (LastUpdatedAfter) y paginación por NextToken desde un cron cada quince minutos, no con un botón. Como los informes hay que esperarlos, el ciclo es crear, sondear y descargar: sondeamos hasta doce veces cada diez segundos. Y como las llamadas de informes comparten cubo, ante un 429 el conector escribe un enfriamiento compartido de 90 segundos y el inventario FBA cae al API en vivo.

El reintento vive en una sola función: 429 y 500, 502, 503 y 504 se reintentan, se respeta Retry-After y, si no viene, se espera un backoff exponencial desde 1,5 segundos con ruido aleatorio para que dos crons no vuelvan a la vez. Si el último intento también falla, el error lleva dentro el Retry-After, la cabecera de cuota y la ruta: el log dice qué cuota se agotó, no «error al sincronizar».

De ahí la regla: lo que escribe va en cola con clave de idempotencia; lo que lee va con marca de agua. Confirmar el envío puede quedar encolado en «pendiente» y entonces la única que envía es un cron cada cinco minutos que coge como mucho 200 albaranes de los últimos tres días, con un pestillo por albarán que impide mandar el mismo tracking dos veces. Precios y stock tienen su propia cola cada minuto; si una escritura falla, otra cola la reintenta cada 180 segundos, veinte veces como mucho por SKU.

Por qué Amazon rompe operaciones cuando no manda Odoo

Si el stock sale de varios sitios o el tracking se gestiona fuera del ERP, llegan las incidencias: pedidos sin mapear, inventario incoherente y postventa más cara. Con los límites delante se ve por qué el canal que publica el stock tiene que ser uno solo: publicarlo dos veces cuesta el doble de cuota. Lo desarrollamos en stock en tiempo real en marketplaces y en vender en varios marketplaces desde un solo Odoo.

Errores frecuentes de Amazon SP-API en Odoo

Casi todos los fallos que vemos vienen de esas tres credenciales, no del código: un redirect URI que apunta a otro Odoo y la vuelta del vendedor acaba en una pantalla que dice que nadie le esperaba; una autorización con version=beta cuando la app ya está publicada; el secreto LWA caducado; el rol restringido sin aprobar, que no da error claro sino direcciones vacías; y el bucle de 429 cuando alguien reintenta a mano mientras el cron también reintenta.

Cada uno tiene un síntoma que no se parece a su causa, así que los reunimos con su diagnóstico en Amazon SP-API y Odoo: errores frecuentes y cómo evitarlos. Si lo tuyo es la puesta en marcha, el recorrido está en cómo integrar Amazon con Odoo 19.

Empieza por lo que más duele

Con los límites delante hay un orden sensato: pedidos, stock y tracking primero, que son las tres llamadas que sostienen el almacén; después listings, precios, FBA o devoluciones si el negocio lo pide. Los informes van al final: no son difíciles, consumen la cuota lenta.

Qué deberías preguntar antes de comprar

• Qué flujos están soportados hoy y por qué API entra cada uno.
• Si la conexión usa tu aplicación o la del proveedor, y quién rota el secreto LWA.
• Qué pasa ante un 429: ¿reintenta, encola, respeta Retry-After, deja rastro?
• Cómo se tratan FBA, devoluciones y direcciones con datos personales.
• Si al confirmar dos veces el mismo envío se manda dos veces el tracking.
• Si el proveedor implanta o solo vende licencia, y en qué versiones mantiene el módulo.

Si la integración no es con Amazon sino con tu propio programa de gestión, el planteamiento es el mismo y lo contamos en conector Odoo para tu software; el catálogo está en módulos y el mapa por problema, en soluciones.

Preguntas frecuentes

Enlaces útiles dentro de FlexigoTech

Lo que hacemos sobre esto