Planes de uso y límites de tasa en la SP-API

La confiabilidad de la API depende del tamaño de su capacidad y recursos para satisfacer las necesidades cambiantes de las aplicaciones a lo largo del tiempo. Esto significa intentar comprender y pronosticar el uso, y luego administrar la frecuencia de las solicitudes para protegerse contra la saturación del servicio en los momentos de mayor uso.

En la Selling Partner API, las solicitudes tienen un límite de frecuencia mediante el token bucket algorithm. El algoritmo se basa en la analogía de un bucket que contiene tokens, donde cada token se puede intercambiar para realizar una solicitud. Los tokens se agregan automáticamente al depósito utilizando una tasa por segundo establecida hasta que se alcanza el tamaño máximo del depósito. El tamaño máximo también se denomina velocidad de ráfaga. Cada solicitud resta un token del depósito. Throttling se produce cuando se realiza una solicitud para la que no hay ningún token disponible porque el depósito está vacío. Una solicitud limitada da como resultado una respuesta de error.

Planes de uso

Las operaciones de Selling Partner API tienen planes de uso asociados que especifican los límites de tarifas. Puede encontrarlos en la documentación de referencia de la API. Las definiciones del plan de uso son:

• Tasa: la cantidad de solicitudes por segundo que se agregan al depósito de tokens y, por lo tanto, se pueden usar para enviar solicitudes sin experimentar limitaciones. Si realiza llamadas continuamente durante un largo período de tiempo, mantenerse por debajo de esta tasa lo ayudará a evitar solicitudes limitadas.
• Ráfaga: el tamaño máximo que puede alcanzar el depósito de fichas. Esto también representa la cantidad máxima de solicitudes que puede acumular con el tiempo y luego enviar simultáneamente suponiendo que el depósito de tokens esté lleno.

Planes de uso Standard

La mayoría de las Selling Partner APIs se rigen por planes de uso estándar. Con un plan de uso Standard, los límites de frecuencia son estáticos para todas las personas que llaman y se basan en nuestros patrones de llamadas esperados para cada operación de la API. Las tarifas del plan de uso predeterminado para cada operación de la ASelling Partner APIs se publican en la referencia de API para esa sección de API. Las personas que llaman a una operación API deben recibir el rendimiento indicado por las tasas predeterminadas. Los seller partners cuyas demandas comerciales requieren un mayor rendimiento pueden ver valores de tasa y ráfaga más altos que los predeterminados si Amazon les ha otorgado una anulación.

Si encuentra que las tasas predeterminadas no son suficientes para su caso de uso, solicite una anulación abriendo un ticket de soporte con nuestro equipo de soporte para desarrolladores.

Planes de uso dinámico

Los planes de uso dinámico solo se aplican a las Selling Partner APIs y operaciones:

Un plan de uso dinámico es uno que se ajusta automáticamente a cada seller partner en función de las necesidades comerciales actuales e históricas de ese negocio. Los límites de tasa predeterminados publicados en la documentación de referencia de API se pueden usar para planificar su aplicación. Sin embargo, debido a que el propósito de los planes de uso dinámico es ajustar esos límites con el tiempo, las tarifas pueden cambiar.

Una variedad de métricas comerciales de seller partner influyen en los ajustes de tarifas. Estas son business metrics only y no incluyen un número histórico de solicitudes de API. Las tarifas no aumentarán dinámicamente porque una aplicación envía solicitud de API con más frecuencia.

Si encuentra que las tarifas dinámicas aún no son suficientes para su caso de uso, solicite una anulación abriendo un ticket de soporte con nuestro equipo de soporte para desarrollador.

El respuesta de header x-amzn-RateLimit-Limit

Cuando envía una solicitud a una operación Selling Partner API, los límites de tasa actuales para esa operación se devuelven en el respuesta de header x-amzn-RateLimit-Limit , según el mejor esfuerzo, solo para los HTTP status codes 20x, 400 y 404. En algunos casos, nuestro mejor esfuerzo para solicitar, recuperar y proporcionar el límite de tasa puede fallar. Esto podría deberse a un error de red aleatorio, nuestro intento de solicitud se aceleró u otros problemas difíciles de predecir. Cuando eso suceda, no fallaremos en una solicitud válida a una operación Selling Partner API. En su lugar, devolveremos la respuesta sin el header.

Esto significa que no debe depender de la presencia del header x-amzn-RateLimit-Limit en una respuesta. En su lugar, verifique la presencia del header antes de intentar usar el valor del límite de velocidad.

El Nunca se debe esperar x-amzn-RateLimit-Limit en la respuesta a una solicitud limitada, no autorizada o no autenticada.

Preguntas frecuentes

General

Los límites de velocidad para una operación son demasiado bajos para mi caso de uso. ¿Se puede aumentar el límite?

Apuntamos a límites del tamaño correcto, con el objetivo de que los patrones de llamadas eficientes, idealmente, nunca se limiten. Si cree que tiene un caso de uso que no hemos tenido en cuenta correctamente, infórmenos abriendo un ticket de soporte con nuestro equipo de soporte para desarrolladores.

¿Cómo debe manejar mi aplicación una respuesta 429?

Un 429 es un status code que se puede volver a intentar. Siéntase libre de volver a intentarlo, pero las solicitudes limitadas repetidas requieren una estrategia de retroceso. Por favor refiérase a respuesta de header x-amzn-RateLimit-Limit , cuando esté disponible, para ver si los límites de frecuencia difieren de sus expectativas.

¿Cómo puedo probar mi aplicación con respecto a sus planes de uso?

Puede probar el manejo de errores 429 utilizando el Selling Partner API sandbox(entorno de pruebas). Sin embargo, no puede probar los límites de frecuencia con el sandbox(entorno de pruebas). Esto se debe a que, si bien las operaciones en producción pueden tener varias tasas, todas las operaciones de sandbox(entorno de pruebas) comparten la misma tasa. Puede ver sus tarifas de uso asignadas en el respuesta de header x-amzn-RateLimit-Limit para cada operación, cuando esté disponible.

¿Puede mi aplicación evitar por completo que se limite?

No. Cualquier cantidad de factores fuera de su control podría resultar en una pequeña cantidad de 429 transitorios. Esto es de esperar y debe tenerse en cuenta en el código de su aplicación.

¿Qué debo hacer si mi aplicación se acelera constantemente?

Si su aplicación se limita constantemente, podría significar que sus patrones de llamada podrían optimizarse aún más. Por ejemplo:

1. Llame con menos frecuencia de acuerdo con sus límites de tarifas.
2. Confíe en las notificaciones automáticas sobre los mecanismos de votación.
3. Utilice las API por lotes donde estén disponibles o intente hacer más con menos llamadas. Por ejemplo, con las API Feeds e Reports , puede enviar o recuperar una gran cantidad de información (es decir, lotes de información) utilizando un número relativamente pequeño de llamadas. En general, compare sus patrones de llamadas con las operaciones en una API para ver si puede hacer el mismo trabajo en menos llamadas.

¿Se acelerará mi solicitud con más frecuencia a medida que obtenga más autorizaciones?

No. Todos los planes de uso son específicos para los pares de selling partner’s de aplicaciones, por lo que su rendimiento crece de forma natural con sus clientes.

¿Cambiarán los límites de tarifas?

Podríamos aumentar los límites de las tasas en cualquier momento. Si alguna vez bajamos los límites de velocidad publicados en la documentación de referencia de la API, le comunicaremos el cambio por adelantado para darle tiempo de actualizar y probar sus aplicaciones antes de que el cambio entre en vigor.

Los límites de tarifas para los planes de uso dinámico (discutidos a continuación) se ajustan automáticamente hacia arriba o hacia abajo según el contexto comercial.

Planes de uso dinámico

¿Aumentarán mis límites de frecuencia si mi aplicación se acelera constantemente?

Las tarifas se basan en las métricas comerciales de un selling partner. Si una aplicación se acelera constantemente, es probable que sus patrones de llamadas no estén alineados con los límites de frecuencia asignados a ese selling partner. Consulte ¿Qué debo hacer si mi aplicación se limita constantemente? Consulte también Los límites de velocidad para una operación son demasiado bajos para mi caso de uso. ¿Se puede aumentar el límite? .

¿Cuál es el objetivo general de los planes de uso dinámico?

Históricamente, hemos observado que los planes de uso homogéneo están sobredimensionados para algunas situaciones y, lo que es peor, subdimensionados para otras. El objetivo de los planes de uso dinámico es aprovechar el contexto comercial conocido de una llamada determinada para establecer los límites correctos para cualquier situación.

¿Qué factores influyen en los planes de uso dinámico?

En general, los límites de tarifas están determinados por el tipo, el tamaño y el comportamiento del negocio del selling partner.

¿Con qué frecuencia cambiarán los límites asociados con un plan de uso determinado?

Nuestro objetivo es evitar cambios frecuentes y perturbadores en los límites. Por lo general, los límites cambiarán tan pronto como detectemos cambios significativos en las métricas comerciales en una cuenta de Selling Partner.

¿Cómo debo codificar mi aplicación para respetar los límites dinámicos?

Aquí hay algunas sugerencias para un buen comportamiento de la aplicación con respecto a los límites de velocidad dinámicos.

1. Leer el header x-amzn-RateLimit-Limit , cuando esté disponible.
2. No codifique los temporizadores.
3. Codifique naturalmente contra eventos en lugar de ejecutarse en un loop. Si haces esto, no necesitarás ningún temporizador. En el ejemplo de un nuevo fijador de precios, actualice los precios en respuesta a las notificaciones de precios en lugar de cada n segundos.