Skip to content

Límites de velocidad

La infraestructura de la API de Braze está diseñada para gestionar grandes volúmenes de datos de toda nuestra base de clientes. Para ello, imponemos límites de velocidad de API por espacio de trabajo.

Un límite de velocidad es el número de solicitudes que puede recibir la API en un periodo de tiempo determinado. Muchos incidentes de denegación de servicio basados en la carga en grandes sistemas son involuntarios —causados por errores en el software o las configuraciones—, no ataques maliciosos. Los límites de velocidad comprueban que esos errores no priven a nuestros clientes de los recursos de la API de Braze. Si se envían demasiadas solicitudes en un periodo de tiempo determinado, es posible que veas respuestas de error con un código de estado 429, que indica que se ha alcanzado el límite de velocidad.

Límites de velocidad por tipo de solicitud

Consulta lo siguiente para conocer los límites de velocidad predeterminados de la API para los diferentes tipos de solicitudes. Estos límites predeterminados pueden aumentarse previa solicitud. Ponte en contacto con tu administrador del éxito del cliente para obtener más información.

Solicitudes con diferentes límites de velocidad

Solicitudes con límites de velocidad compartidos

Las siguientes solicitudes tienen un límite de velocidad de 250.000 solicitudes por hora, compartido entre ellas.

¿Qué se considera la misma audiencia única?

Esto se aplica a los tres puntos finales siguientes: /messages/send, /campaigns/trigger/send y /canvas/trigger/send.

Para estos puntos finales, se considera que las solicitudes de difusión se dirigen a la misma audiencia única cuando se cumplen todas las condiciones siguientes:

  • La campaña o el Canvas que se desencadena (el campaign_id o canvas_id en tu solicitud de API, si se especifica)
  • La audiencia a la que te diriges (los segmentos o filtros, o para las campañas de API, el segment_id en tu solicitud de API)
  • Los filtros de audiencia conectados (el objeto audience en tu solicitud de API, si se especifica)

Cada combinación única de estos atributos cuenta como una audiencia distinta, por lo que el límite de velocidad adicional para cada audiencia única se aplica a cada combinación de forma independiente.

Procesamiento por lotes de las solicitudes de API

Las API de Braze están diseñadas para soportar el procesamiento por lotes. Con el procesamiento por lotes, Braze puede recibir tantos datos como sea posible en una sola llamada a la API, para que no tengas que hacer muchas llamadas a la API. Para Braze, es más eficiente procesar los datos por lotes que procesarlos llamada a llamada. Por ejemplo, gestionar 1.000 llamadas de API por lotes requiere menos recursos que gestionar 75.000 llamadas individuales. El procesamiento por lotes es extremadamente importante para cualquier aplicación que pueda requerir más de 75.000 llamadas por hora.

Solicitudes por lotes para el punto final de seguimiento de usuarios

Cada solicitud /users/track puede contener hasta 75 objetos en total combinados entre attributes, events y purchases. Cada objeto puede actualizar un usuario. Un mismo perfil de usuario puede ser actualizado por varios objetos.

Límites de velocidad heredados

Para los clientes con límites de velocidad heredados, cada array (attributes, events y purchases) puede contener hasta 75 objetos de forma independiente, para un máximo combinado de hasta 225 objetos por solicitud.

Para más información sobre los límites de velocidad de /users/track, consulta POST: Crear y actualizar usuarios.

Las solicitudes realizadas a este punto final generalmente comenzarán a procesarse en este orden:

  1. Atributos
  2. Eventos
  3. Compras

Procesamiento por lotes de las solicitudes de puntos finales de mensajería

Una única solicitud a los puntos finales de mensajería puede llegar a cualquiera de los siguientes:

  • Hasta 50 external_ids específicos, cada uno con parámetros de mensaje individuales
  • Un segmento de cualquier tamaño creado en el panel de Braze, especificado por su segment_id
  • Usuarios que coinciden con filtros de audiencia adicionales de cualquier tamaño, definidos en la solicitud como un objeto de audiencia conectada

Ejemplo de solicitud por lotes

En el siguiente ejemplo se utiliza external_id para realizar una llamada de API para correo electrónico y SMS.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

curl --location --request POST 'https://rest.iad-01.braze.com/v2/subscription/status/set' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR-REST-API-KEY' \
--data-raw '{
  "subscription_groups":[
    {
      "subscription_group_id":"subscription_group_identifier",
      "subscription_state":"subscribed",
      "external_ids":["example-user","[email protected]"]
    },
    {
      "subscription_group_id":"subscription_group_identifier",
      "subscription_state":"subscribed",
      "external_ids":["example-user","[email protected]"]
    }
  ]
}

Control de los límites de velocidad

Cada solicitud de API enviada a Braze devuelve la siguiente información en los encabezados de respuesta:

Esta información se incluye intencionadamente en el encabezado de la respuesta a la solicitud de API en lugar de en el panel de Braze. Esto permite que tu sistema reaccione mejor en tiempo real mientras interactúas con nuestra API. Por ejemplo, si el valor de X-RateLimit-Remaining cae por debajo de un determinado umbral, puede que quieras ralentizar el envío para asegurarte de que se envían todos los correos electrónicos transaccionales. O, si llega a cero, es conveniente pausar todos los envíos hasta que transcurra el tiempo especificado en X-RateLimit-Reset.

Si tienes preguntas sobre los límites de la API, ponte en contacto con tu administrador del éxito del cliente o abre un ticket de soporte.

Retardo óptimo entre puntos finales

Comprender el retraso óptimo entre puntos finales es crucial a la hora de realizar llamadas consecutivas a la API de Braze. Los problemas surgen cuando los puntos finales dependen del procesamiento satisfactorio de otros puntos finales y, si se los llama demasiado pronto, podrían provocar errores. Por ejemplo, si estás asignando a los usuarios un alias a través de nuestro punto final /user/alias/new, y luego utilizas ese alias para enviar un evento personalizado a través de nuestro punto final /users/track, ¿cuánto tiempo debes esperar?

En condiciones normales, el tiempo que tarda en producirse la consistencia eventual de nuestros datos es de 10 a 100 ms (1/10 de segundo). Sin embargo, puede haber casos en los que esa consistencia tarde más en producirse, por lo que te recomendamos que dejes pasar 5 minutos entre una llamada y otra para minimizar la probabilidad de error.

Restablecimiento del límite de velocidad

Los límites de velocidad se restablecen a la hora en punto, no en una ventana deslizante. Por ejemplo, si el límite es de 250.000 solicitudes por hora, podrías hacer 50.000 solicitudes entre las 10:00 PM y las 10:59 PM y otras 250.000 solicitudes entre las 11:00 PM y las 11:59 PM, porque el contador se restablece al inicio de cada hora.
Github   Editar esta página en GitHub
New Stuff!