Fees de SP-API y Optimización de Llamadas

Resumen rápido

Desde el 31 de enero de 2026, Amazon cobra a los desarrolladores de terceros (no privados) por usar SP-API. La tarifa base es de $1.400/año más tarifas mensuales según el volumen de llamadas. Los desarrolladores privados (que usan la API solo para sus propias cuentas) no pagan estas tarifas. La mejor forma de ahorrar dinero es optimizar el código para hacer el menor número posible de llamadas GET.

---

Conceptos importantes

• Third-party developer: Desarrollador que crea apps para otros vendedores (SaaS, agencias, etc.). Paga fees.
• Private developer: Desarrollador que usa la API solo para sus propias cuentas de vendedor. No paga fees adicionales.
• GET calls: Las llamadas de lectura de datos son las que cuenta Amazon para el fee mensual.
• Annual subscription fee: $1.400/año de tarifa base (independientemente del volumen).
• Monthly fee: Tarifa adicional por mes según el número de GET calls. Se añade a la tarifa anual.
• Polling: Patrón de consulta repetida (bucle que llama a la API cada X segundos o minutos). Es el patrón más ineficiente y costoso.
• Push notification: Amazon te avisa cuando hay algo nuevo. Patrón eficiente que elimina el polling.

---

Estructura de tarifas (desde enero 2026)

Calls GET/mes	Tarifa mensual adicional
0 – 2.5 millones	$0 (solo la tarifa anual)
2.5M – 25 millones	$1.000/mes
25M – 250 millones	Escala progresiva
Más de 250 millones	Hasta ~$10.000/mes (enterprise)

Tarifa anual base: $1.400/año (obligatoria para todos los third-party developers integrados con SP-API). Tienes que registrar una tarjeta de crédito en Developer Central, o Amazon cortará el acceso.

¿Quién paga y quién no?

Perfil	¿Paga fees?
Private developer (solo tus cuentas)	No
Third-party developer (apps para otros sellers)	Sí
SaaS platform (Jungle Scout, Helium 10, etc.)	Sí (enterprise tier)

---

Técnicas de optimización

1. Reports API en lugar de polling de Orders API

Problema: Muchas apps obtienen pedidos llamando a GetOrders cada pocos minutos en un bucle.

# MAL: esto genera miles de llamadas
while True:
    orders = get_orders(token, marketplace_id)
    save_orders(orders)
    time.sleep(300)  # cada 5 minutos = 8.640 calls/mes

Solución: Pedir un informe de pedidos una vez al día y descargarlo.

# BIEN: 1 sola llamada al día para obtener todos los pedidos del día
report_id = create_report(token, "GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL", marketplace_id)
# Esperar la notificación REPORT_PROCESSING_FINISHED
# Descargar y procesar el informe

Ahorro: De ~8.640 GET calls/mes a ~30 GET calls/mes.

---

2. Notifications API en lugar de polling para pedidos nuevos

Problema: Consultar GetOrders cada 5 minutos para detectar pedidos nuevos.

Solución: Suscribirse a ORDER_CHANGE y que Amazon avise cuando llega un pedido nuevo.

# Solo haces una llamada al pedido específico cuando llega la notificación
setup_notifications(
    token, endpoint, marketplace_id,
    sqs_arn, ["ORDER_CHANGE"]
)

# Cuando llega un mensaje de SQS:
order_id = notification["payload"]["orderId"]
order = get_order(token, endpoint, order_id)  # 1 sola llamada, bajo demanda

Ahorro: De miles de llamadas/mes a solo las necesarias cuando llegan pedidos.

---

3. Reports API + Notifications para informes (no polling)

Problema: Bucle comprobando si el informe está listo.

# MAL: genera muchas llamadas innecesarias
while True:
    status = get_report_status(token, report_id)
    if status == "DONE":
        break
    time.sleep(30)  # 20 llamadas en 10 minutos

Solución: Suscribirse a REPORT_PROCESSING_FINISHED y que Amazon avise.

# BIEN: 0 llamadas de polling, Amazon avisa cuando está listo
# 1. Crear el informe
# 2. Guardar el reportId
# 3. Cuando llega notificación SQS → descargar inmediatamente

Ahorro: Elimina hasta 100x las llamadas a GetReport.

---

4. SearchCatalogItems en lugar de GetCatalogItem (batching)

Problema: Obtener datos de 100 ASINs llamando a GetCatalogItem 100 veces.

# MAL: 100 llamadas, 2 items/segundo = 50 segundos
for asin in asins:
    item = get_catalog_item(token, endpoint, marketplace_id, asin)

Solución: Usar SearchCatalogItems con identifiers para obtener 20 ASINs por llamada.

# BIEN: 5 llamadas, 2 calls/segundo = 2.5 segundos y 20x menos calls
def get_catalog_items_batch(token, endpoint, marketplace_id, asins):
    results = []
    for i in range(0, len(asins), 20):
        batch = asins[i:i+20]
        response = requests.get(
            f"{endpoint}/catalog/2022-04-01/items",
            headers={"x-amz-access-token": token},
            params={
                "marketplaceIds": marketplace_id,
                "identifiers": ",".join(batch),
                "identifiersType": "ASIN",
            }
        )
        results.extend(response.json().get("items", []))
    return results

Ahorro: 20x menos llamadas para la misma cantidad de datos.

---

5. Listings/Inventory reports en lugar de GetListingsItem repetido

Para monitorizar tu inventario o listings, usa los informes:

# En lugar de llamar GetListingsItem para cada SKU:
# Pide el informe completo
report_id = create_report(
    token,
    "GET_MERCHANT_LISTINGS_ALL_DATA",  # Todos tus listings
    marketplace_id
)

---

Resumen de optimizaciones y ahorro estimado

Situación	Antes	Después	Ahorro
Monitorizar pedidos nuevos	GetOrders cada 5 min	ORDER_CHANGE notification	~99%
Descargar datos de pedidos	GetOrders diario	Report de pedidos diario	~95%
Estado de informe	GetReport cada 30s	REPORT_PROCESSING_FINISHED	~99%
Datos de catálogo	GetCatalogItem × N	SearchCatalogItems (20x)	~95%
Inventario actual	GetListingsItem × N	Informe de listings	~99%

---

Errores comunes

• Creer que los fees afectan a todos: Los private developers no pagan. Si usas SP-API solo para tu negocio propio, no te aplica.
• No registrar la tarjeta de crédito: Amazon cortará el acceso a tu app si no tienes método de pago registrado (para third-party developers).
• No auditar el número de llamadas: Antes de los fees era gratis ser ineficiente. Ahora conviene medir cuántas llamadas hace tu app al mes.
• Confundir calls GET con POST/PATCH: Los fees son principalmente por GET calls (lectura de datos). Las operaciones de escritura (feeds, listings) tienen otra estructura.

---

Qué debo saber antes de programarlo

• Si construyes una app para uso personal (private developer), no pagas fees y puedes ignorar este tema para tus costes.
• Si construyes una SaaS para otros vendedores, el coste de la API es un factor que debes incluir en tu modelo de negocio.
• El umbral de 2.5 millones de GET calls/mes sin cargo mensual adicional es suficiente para la mayoría de apps pequeñas y medianas. Superar ese umbral cuesta $1.000/mes, que es un salto grande.
• La mejor inversión de tiempo es: implementar Notifications API desde el principio. Elimina el polling y reduce drásticamente los costes y la complejidad a largo plazo.
• Ver 09-notifications-api.md para la implementación completa.

---

Pendiente de revisar

• ¿Cómo se contabiliza exactamente el número de GET calls en el billing de Amazon?
• ¿Hay algún panel en Developer Central donde ver el consumo actual de calls?
• ¿Las llamadas de autenticación (obtener access token) cuentan para el billing?