Lanzamientos recientes

En esta página, se proporciona información sobre los cambios más recientes en RCS para empresas.

30 de octubre de 2026

Modificado

Redacción de los motivos para cancelar la suscripción

Actualizamos la experiencia de cancelación de suscripción en Mensajes de Google para mejorar la claridad y reducir la ambigüedad de las categorías. Este cambio se lanzará de forma gradual hasta fines de noviembre, por lo que la interfaz actualizada puede tardar un poco en aparecer para todos los usuarios.

Antes Después
Motivos de la anulación de la suscripción antes Motivos de la anulación de la suscripción después de

Funciones clave

  • Frases en primera persona: Se actualizaron las etiquetas de los motivos de cancelación de la suscripción para usar un lenguaje claro en primera persona:
    • Demasiados mensajes
    • Nunca me registré para obtener este servicio (antes, Usuarios que nunca se registraron)
    • Ya no me interesa (antes, Ya no me interesa)
    • Parece una estafa (anteriormente, Spam)
    • Otro
  • Orden aleatorio: Para reducir el sesgo de selección, las primeras cuatro opciones se muestran en un orden aleatorio para cada usuario. Este orden se mantiene constante en todas las visitas del usuario, y Otros permanece fijo en la parte inferior.
  • Informes de Analytics: Los comentarios sobre las cancelaciones de suscripciones se siguen informando en la Descripción general de Analytics en las categorías de métricas correspondientes.

Acción obligatoria

No es necesario que realices ninguna acción.

Para obtener más detalles, consulta la guía actualizada Recibe eventos.

29 de octubre de 2026

Nuevo

Para evitar condiciones de carrera en las que los mensajes de corta duración vencen antes de que las redes de los operadores y los dispositivos de los usuarios puedan procesar la entrega de mensajes y devolver las confirmaciones de entrega, la plataforma de RCS para empresas establece un vencimiento mínimo de seis segundos para todos los mensajes de agentes que especifican ttl o expireTime.

Qué cambiará

Si una solicitud especifica una duración de ttl entre cero y seis segundos, o una marca de tiempo de expireTime de menos de seis segundos después del envío del mensaje, la plataforma extiende automáticamente el vencimiento a seis segundos. La marca de tiempo expireTime en la respuesta de la API refleja este valor ajustado.

Las solicitudes con un ttl de cero o menos, o un expireTime en el envío del mensaje o antes de este, devuelven un error 400 INVALID_ARGUMENT.

Qué debes hacer

  • Actualiza tus valores de vencimiento: Si tu agente establece ttl o expireTime, asegúrate de que el vencimiento sea de al menos seis segundos después del envío del mensaje.
  • Alineación con las notificaciones de webhook: Durante el período de ajuste automático, una solicitud con un ttl de menos de seis segundos (por ejemplo, dos segundos) permanecerá activa durante seis segundos.
    • Activa el resguardo solo cuando recibas la notificación del webhook de revocación que indica que el mensaje venció.
    • Agrega un breve búfer después de la ventana de ttl para permitir que se asienten las confirmaciones de entrega que lleguen tarde.

Para obtener más información, incluidas las prácticas recomendadas, consulta la guía Envía mensajes y la referencia de phones.agentMessages.

8 de octubre de 2026

Mejora de la documentación

Actualizamos la documentación de los informes de facturación y registros de actividad estándar y de los informes de facturación de EE.UU. para aclarar que los informes de facturación y los archivos de registro de actividad están codificados en UTF-8 sin una marca de orden de bytes, usan saltos de línea para los finales de línea y, además, incluyen una fila de encabezado.

7 de octubre de 2026

Modificado

El video de vista previa del agente ahora es opcional para los lanzamientos administrados por Google

Para ayudarte a lanzar agentes de RCS para empresas con mayor rapidez y facilitar la incorporación, ya no es estrictamente necesario un video de vista previa del agente para los lanzamientos en operadores administrados por Google. Ahora puedes elegir proporcionar un video de vista previa del agente o transcripciones de texto detalladas paso a paso en la sección Experiencia del agente del cuestionario de lanzamiento.

Qué debes hacer

Cuando envíes una solicitud de lanzamiento para operadores administrados por Google, debes demostrar claramente la experiencia de tu agente. Debes proporcionar un video de vista previa del agente o transcripciones detalladas paso a paso para los siguientes campos:

  • Descripción del activador: Son las acciones específicas del usuario o los eventos de backend que activan los mensajes.
  • Descripción de la interacción: Es una transcripción del flujo de conversación del agente, incluidos los recorridos del usuario de muestra y las respuestas sugeridas y acciones.
  • Descripción del rechazo: Las palabras clave de rechazo admitidas (como STOP) y el mensaje de confirmación exacto que se envía a los usuarios.

Para conocer las prácticas recomendadas y las plantillas de ejemplo por caso de uso (OTP, transaccional, promocional y de uso múltiple), consulta Describe la experiencia de tu agente.

25 de agosto de 2026

Nuevo

Informes de facturación de socios

Presentamos los informes de facturación de socios, que proporcionan recuentos diarios agregados de eventos facturables, agrupados por agente, tipo de evento y operador. Este resumen de alto nivel proporciona estadísticas valiosas y la visibilidad necesaria para administrar tu tráfico.

Los informes se generan diariamente en formato CSV y se entregan de forma segura con el servicio de SFTP de Google.

Para obtener información sobre cómo configurar tus credenciales de SFTP y acceder a estos informes, consulta la guía Informes de facturación para socios.

31 de julio de 2026

Mejora de la documentación

Actualizamos la documentación de Envía mensajes para aclarar el comportamiento de la compresión y transcodificación automáticas de contenido multimedia en RCS para empresas.

20 de julio de 2026

Nuevo

Nueva función de registro de auditoría: Captura acting_party en la API de RBM Operations

Para ayudarte a mantener registros de auditoría precisos, presentamos un parámetro acting_party opcional para la API de brands.agents.updateLaunch.

Por qué realizamos este cambio

Cuando se actualiza el estado de lanzamiento de un agente con la API de RBM Operations, el campo ID de usuario en los registros del historial se establece de forma predeterminada en "Llamada a la API" porque la autenticación basada en cuentas de servicio carece de contexto de usuario.

Mejoras clave

  • Acciones de la API identificables: Los emisores de llamadas a la API ahora pueden proporcionar de forma explícita un parámetro acting_party para representar la dirección de correo electrónico o el identificador del usuario que ejecuta la acción.
  • Visibilidad de la consola y del webhook: El identificador capturado es visible en el Historial del agente de la consola de administración y se incluye en las notificaciones de webhook de AgentLaunchEvent.
  • Coherencia en el registro de auditoría: Los registros de las acciones iniciadas por la API ahora coinciden con los generados por las aprobaciones manuales de la consola.

Cómo usar el parámetro nuevo

Para comenzar a capturar identificadores de usuario, agrega el parámetro de consulta acting_party a tus solicitudes a la API para brands.agents.updateLaunch.

Para obtener más detalles, consulta la guía actualizada Cambia el estado de lanzamiento del agente.

13 de julio de 2026

Nuevo

Nuevo encabezado HTTP de webhook

La plataforma de RCS para empresas ahora incluye un encabezado HTTP X-Goog-Webhook-Type en todas las solicitudes de webhook. Este encabezado te permite identificar los tipos de solicitudes de todos los webhooks entrantes de forma instantánea, sin necesidad de analizar el cuerpo JSON.

Para obtener más detalles, consulta la guía actualizada de Webhooks.

6 de julio de 2026

Modificado

Métricas de cancelación de suscripción de la descripción general de Analytics

La Consola para desarrolladores de RCS para empresas ahora muestra las métricas de cancelación de suscripción de los agentes no promocionales en el resumen de Analytics, en reemplazo del marcador de posición "N/A".

26 de junio de 2026

Nuevo

Orden personalizado para las listas de agentes

El extremo brands.agents.list ahora admite el parámetro de consulta orderBy. Esto permite que los socios ordenen sus agentes por nombre, hora de creación o marca de tiempo de la última actualización.

Mejoras clave

  • Varios campos de ordenamiento: Ahora puedes ordenar tus agentes con los siguientes campos:
    • updateTime: Ordena cronológicamente por la marca de tiempo de la última actualización.
    • displayName: Ordena alfabéticamente por el nombre del agente legible por humanos.
    • agentId: Ordena por el identificador único del agente generado por el sistema.
  • Control de dirección: Puedes establecer la dirección de ordenamiento agregando un sufijo " asc" o " desc" al nombre del campo. Los campos especificados sin un sufijo se ordenarán de forma ascendente de manera predeterminada.
  • Orden predeterminado: Si se omite el parámetro orderBy, la lista se ordena de forma predeterminada por agentId en orden ascendente.

Para obtener más información, consulta la documentación de referencia actualizada de brands.agents.list.

11 de junio de 2026

Mejora de la documentación

Actualizamos nuestra documentación para aclarar que los socios pueden cambiar el estado de lanzamiento de un agente de PENDING a UNLAUNCHED para cancelar una solicitud de lanzamiento pendiente.

Para obtener más detalles, consulta la guía Recibe eventos.

22 de mayo de 2022

Aplicación de extremos regionales para las verificaciones de capacidad por lotes

Modificado

A partir del 4 de mayo de 2026, el método users.batchGet requiere el uso de extremos regionales. Las solicitudes por lotes se deben enviar al extremo de la API que corresponda a la región geográfica de los números de teléfono de ese lote.

Por qué realizamos este cambio

Optimizar el rendimiento y la confiabilidad de la API, y contener el impacto de cualquier posible interrupción

Qué debes hacer

  1. Actualiza tu aplicación para llamar al extremo regional correcto para tus solicitudes de users.batchGet.
  2. Asegúrate de que cada solicitud de users.batchGet contenga números de teléfono de una sola región. Las solicitudes que contengan números de teléfono de regiones mixtas o que se envíen al extremo regional incorrecto fallarán con un error 400 de solicitud incorrecta.

Qué se mantendrá igual

Las verificaciones de capacidad única (phones.getCapabilities) y el envío de mensajes no se ven afectados por esta aplicación de medidas por incumplimiento en este momento. Sin embargo, te recomendamos que uses APIs regionalizadas para todas las llamadas, de modo que puedas optimizar el rendimiento de la API ahora y prepararte para futuras actualizaciones.

12 de mayo de 2026

Nuevo

Sugerencias persistentes para mensajes de texto

RCS para empresas ahora admite sugerencias persistentes para mensajes de texto independientes. A diferencia de las sugerencias transitorias estándares que desaparecen cuando continúa una conversación, las sugerencias persistentes se muestran dentro de la burbuja de mensaje y permanecen fijas durante toda la conversación.

Por qué realizamos este cambio

Esta función permite que los usuarios vuelvan a realizar acciones útiles, como abrir una URL, marcar un número o ver una ubicación, mucho después de que se envió el mensaje inicial, lo que proporciona una experiencia del usuario más coherente y confiable.

Las sugerencias persistentes de "Abrir una URL" muestran la URL de destino directamente dentro del botón para aumentar la confianza del usuario y reducir la "duda de hacer clic" que causan los vínculos desconocidos.

Tipos de mensajes admitidos

  • Compatibles: Mensajes de texto independientes.
  • No se admiten: Mensajes multimedia independientes (imagen, video, GIF, PDF o audio). Para estos casos de uso, utiliza tarjetas enriquecidas.

Cómo combinar sugerencias

Puedes combinar sugerencias persistentes y transitorias en un solo mensaje de texto. Cada sugerencia debe "aceptar" ser persistente.

  • Límite total: Un solo mensaje de texto puede admitir hasta 11 sugerencias en total.
  • Sugerencias persistentes: Hasta cuatro sugerencias (que se muestran dentro de la burbuja)
  • Sugerencias transitorias: Hasta 11 sugerencias transitorias (se muestran fuera de la burbuja).

Clientes compatibles con las sugerencias persistentes

  • Compatibilidad: Mensajes de Google (versión 20260225.00 o posterior)
  • No se admiten: Las versiones de Mensajes de Google anteriores a la 20260225.00, iOS y Mensajes de Samsung.

Para obtener más detalles, consulta nuestra guía de sugerencias actualizada.

27 de abril de 2026

Modificado

Actualización de los estándares de desarrollo de la marca y verificación de RBM en Mensajes de Google

Presentamos actualizaciones de la verificación y el desarrollo de la marca de RCS para empresas con el objetivo de mejorar la confianza de los usuarios y alinearnos con los estándares de Google. Estas actualizaciones afectan la apariencia de los agentes en la lista de conversaciones, la pantalla de conversación y los detalles de la conversación de Mensajes de Google.

Mejoras clave

  • Nueva forma del logotipo: El logotipo ahora es un cuadrado redondeado en Mensajes de Google. La transición a la nueva forma de cuadrado redondeado es automática.

    Nota: Si tu logotipo actual es un círculo sobre un fondo transparente, se seguirá mostrando como un círculo en la app de Mensajes de Google. Te recomendamos que subas manualmente una imagen de fondo completo para asegurarte de que se vea mejor en la nueva IU. Para obtener más información, consulta Edita la información del agente.

  • Marca de verificación: Los agentes verificados ahora incluyen una marca de verificación. La marca de verificación aparecerá automáticamente para los agentes que hayan completado el proceso de verificación.

Antes Después
Logotipo circular del agente Logotipo del agente con esquinas redondeadas

27 de abril de 2026

Mejora de la documentación

Actualizamos la documentación de Webhooks con nuevas prácticas recomendadas para administrar webhooks, específicamente abordando cómo manejar los riesgos de las colas de socios compartidas y evitar fallas en la entrega de mensajes.

Para obtener más información, consulta la guía actualizada de Webhooks.

6 de abril de 2026

Nuevo

Sube y borra documentos de verificación de agentes con la API de Business Communications

Para agilizar el proceso de verificación de agentes, presentamos nuevos métodos en la API de Business Communications que permiten a los socios subir y borrar documentos de respaldo. Esta función es opcional.

Mejoras clave

  • Nuevos métodos de la API: Ahora los socios pueden usar los siguientes métodos para administrar los archivos adjuntos de verificación:
  • Visibilidad del operador: En el caso de los lanzamientos administrados por el operador, los documentos subidos se comparten con cada operador que hayas seleccionado para el lanzamiento.

Detalles técnicos y límites

  • Compatibilidad con archivos: Inicialmente, la API admite archivos PDF.
  • Tamaño máximo del archivo: 50 MB por archivo
  • Límite de cantidad: Hasta 5 documentos únicos por agente.

Para obtener más información sobre el proceso de verificación, consulta Envía información de verificación.

1 de abril de 2026

Nuevo

Límites de tráfico entre agentes para agentes promocionales con baja reputación en India

Presentamos un límite de tráfico entre agentes para reducir la fatiga de la bandeja de entrada de los usuarios suscriptores en India. Este nuevo límite restringe la cantidad total de mensajes promocionales que un usuario puede recibir de todos los agentes con baja reputación por día.

Este límite se aplica a todos los agentes con baja reputación. Los agentes con reputación alta y media están exentos de esta restricción entre agentes.

Para obtener una explicación detallada de estos nuevos límites de tráfico y otras reglas empresariales, consulta la página Casos de uso y reglas empresariales de los agentes.

1 de abril de 2026

Nuevo

Nuevos controles de visibilidad: Archiva y oculta agentes

Para ayudar a administrar el desorden de la consola, presentamos nuevos controles de visibilidad para socios y operadores. Estas funciones te permiten quitar agentes antiguos o sin usar de sus vistas principales en la consola y a través de la API sin afectar el estado operativo de los agentes.

Para socios: Archiva y desarchiva agentes

Puedes archivar o desarchivar agentes que se encuentren en un estado inactivo (UNLAUNCHED, SUSPENDED o REJECTED). No puedes archivar agentes que estén LAUNCHED o PENDING en ninguna red de operador.

Funciones clave

  • Consola para desarrolladores de RCS para empresas: Archiva o desarchiva agentes de forma individual o masiva (hasta 100). Para obtener más detalles, consulta Archiva o desarchiva un agente.
  • API de Management: Administra de forma programática el estado de archivo de un agente. Para obtener más información, consulta Cómo archivar o desarchivar un agente.
  • Vistas filtradas: De forma predeterminada, los agentes archivados se excluyen de la lista principal. Para incluir los agentes archivados en sus resultados, usa filtros en la consola o parámetros en la API.

Para operadores: Oculta y muestra agentes

Puedes ocultar o mostrar los agentes que se encuentran en un estado inactivo (SUSPENDED o REJECTED) en tu red. No puedes ocultar un agente si su estado de lanzamiento en tu red es LAUNCHED o PENDING.

Funciones clave

  • Consola de administración: Oculta y muestra agentes de forma individual o masiva (hasta 100). Para obtener más información, consulta Oculta o muestra un agente.
  • API de Operations: Administra el estado oculto de un agente para tu red. Para obtener más información, consulta Oculta o muestra agentes.
  • Vistas filtradas: De forma predeterminada, los agentes marcados como ocultos se excluyen de la lista principal. Para ver estos agentes, usa filtros en la consola o parámetros en la API.

10 de marzo de 2026

Modificado

Actualizamos las transiciones de estado de lanzamiento permitidas cuando se administran agentes a través de la API de RBM Operations, la API de Business Communications, la Consola de administración y la Consola para desarrolladores de RCS para empresas. Esto garantiza una lógica y una sincronización coherentes entre la API y la consola.

Estas son las transiciones de estado de lanzamiento permitidas actualizadas:

Iniciada por el operador

  • Desde PENDING hasta LAUNCHED o REJECTED
  • Desde LAUNCHED hasta SUSPENDED
  • Desde SUSPENDED hasta LAUNCHED o UNLAUNCHED

Iniciada por el socio

  • De UNSPECIFIED, UNLAUNCHED o REJECTED a PENDING

9 de marzo de 2026

Modificado

Transparencia de la URL en la acción sugerida "Abrir una URL"

Mensajes de Google ahora muestra la dirección URL subyacente directamente en la acción "Abrir una URL" para las sugerencias en la tarjeta de tarjetas enriquecidas y carruseles. Para obtener más información, consulta Abre una URL.

Antes Después
Tarjeta enriquecida sin URL Tarjeta enriquecida con URL

Con la publicación de la URL, buscamos lo siguiente:

  • Fomenta la confianza de los usuarios: Reduce la fricción y la "duda antes de hacer clic" que causan los vínculos desconocidos.
  • Genera participación: Establece hábitos de uso coherentes y confiables en RCS para empresas.
  • Implementación: Esta función se habilita automáticamente; no se requieren cambios técnicos de integración ni de API de tu parte.
  • Audita tus vínculos: Asegúrate de que tus URLs de destino sean concisas y coherentes con tu marca.
  • Revisa la UX: Verifica tus acciones sugeridas actuales de "Abrir una URL" en tarjetas enriquecidas y carruseles para asegurarte de que el texto visible y la URL que ahora es visible no se sientan redundantes ni desordenados.

28 de febrero de 2026

Modificado

Baja de la API para el recurso phones.testers

Para proporcionar un control más integral, lanzamos la nueva API de verificadores, que permite administrar todo el ciclo de vida de los verificadores. Ahora puedes enviar o volver a enviar invitaciones, obtener el estado y quitar verificadores de manera programática.

Debido a esta funcionalidad expandida, dejamos de usar el recurso phones.testers heredado.

Para garantizar que las pruebas de tus agentes no se interrumpan, todos los socios deben migrar sus implementaciones al nuevo y optimizado recurso de la API de verificadores. Los agentes que no hayan migrado no podrán invitar ni administrar dispositivos de prueba después de esta fecha.

Recurso Estado
phones.testers Obsoleto
verificadores Actual

Qué debes hacer:

  1. Revisa la nueva referencia de la API de verificadores y la guía actualizada para configurar un dispositivo de prueba.
  2. Actualiza el código existente que llama al método phones.testers.create para usar los nuevos extremos de recursos testers.
  3. Implementa y prueba la lógica nueva.

16 de febrero de 2026

Nuevo

Nuevos campos en la respuesta de analytics.agentPerformances.list con métricas adicionales

El método analytics.agentPerformances.list de la API de RCS Business Messaging ahora incluye campos adicionales en el objeto AgentPerformance relacionados con los datos de Unsubscribe Reason y Spam Trend.

12 de febrero de 2026

Mejora de la documentación

Actualizamos la documentación de Envía mensajes con una nueva sección Tiempo de actividad (TTL) de un mensaje para aclarar el comportamiento esperado de las notificaciones y proporcionar recomendaciones para administrar casos extremos de entrega.

5 de febrero de 2026

Nuevo

Nueva página de asistencia para comunicarse con RCS para empresas

Reemplazamos el vínculo "Enviar un correo electrónico al equipo de asistencia de RBM" por una nueva página para comunicarse con el equipo de asistencia de RCS para empresas.

Todas las solicitudes de asistencia técnica ahora se deben iniciar a través del formulario de contacto de asistencia vinculado en esta página, lo que garantiza que los problemas se capturen y enruten con precisión para una resolución más rápida.

Para ayudarte a preparar el envío, la página incluye una guía de inicio rápido en la que se describe la información obligatoria que se requiere para varias categorías de problemas.

5 de febrero de 2026

Mejora de la documentación

Actualizamos la documentación de Envía eventos y phones.agentEvent.create con información sobre el comportamiento de entrega de los eventos de agente READ y IS_TYPING en RCS para empresas.

  • Las actualizaciones especifican que los eventos READ son persistentes y se almacenan durante un máximo de 30 días si un usuario tiene habilitados los RCS, pero no se puede comunicar con él, mientras que los eventos IS_TYPING siguen siendo efímeros y vencen después de aproximadamente 20 segundos.

30 de enero de 2026

Nuevo

Comentarios opcionales para las aprobaciones de lanzamiento de agentes

Ahora los operadores pueden proporcionar comentarios adicionales cuando aprueban las solicitudes de lanzamiento de agentes.

Cambios en la consola

Anteriormente, cuando se administraban agentes en la consola de administración, los operadores podían proporcionar un comentario con un motivo solo cuando rechazaban, suspendían o daban de baja a un agente.

Con esta actualización, presentamos un campo de comentario opcional para el proceso de aprobación. Esto permite que los operadores compartan contexto importante directamente con los propietarios de los agentes en el momento de la aprobación. Para obtener más información, consulta Administra agentes en tu red.

Los comentarios proporcionados durante la aprobación se registran en el Historial del agente de las consolas de Administración y Business Communications.

Cambios en la API de operaciones de RBM

El campo comment ahora admite todas las transiciones de estado cuando cambias el estado de lanzamiento de un agente. Ahora, los transportistas pueden proporcionar un motivo opcional para cualquier cambio de estado, lo que mejora la comunicación y el mantenimiento de registros. Para obtener más información, consulta Administra agentes con la API de RBM Operations.

15 de enero de 2026

Nuevo

Las notificaciones de tarjetas enriquecidas y carruseles en Mensajes de Google ahora incluyen una vista previa del contenido multimedia, junto con el título y la descripción.

Las vistas previas de contenido multimedia solo se muestran en los siguientes casos:

  • Tarjetas enriquecidas: El contenido multimedia de la tarjeta es una imagen o tiene una miniatura.
  • Carruseles: El contenido multimedia de la primera tarjeta es una imagen o tiene una miniatura.
Notificación contraída Notificación expandida
Notificación contraída Notificación expandida

Por qué realizamos este cambio

Para aumentar la participación con tus mensajes

Acción obligatoria

No es necesario que realices ninguna acción.

Nuevo

Uso compartido de archivos para la verificación de agentes

Para agilizar el proceso de aprobación de agentes, los socios ahora tienen la opción de subir documentos de respaldo directamente en la Consola para desarrolladores de RCS para empresas.

Mejoras clave

  • Carga directa: Los socios ahora pueden subir cartas de autorización y otros documentos de respaldo directamente a la Consola para desarrolladores de RCS para empresas. Para obtener más información, consulta Cómo enviar información de verificación. Ten en cuenta que, incluso si se proporciona una carta de autorización, el método de autorización principal para los lanzamientos en operadores administrados por Google sigue siendo el correo electrónico.
  • Visibilidad: Los operadores que usan la Consola del administrador pueden ver estos documentos subidos para acelerar su revisión. Para obtener más información, consulta Administra agentes en tu red.
  • Opciones de verificación flexibles: La nueva función complementa nuestra verificación estándar basada en correo electrónico, que sigue activa.

Si bien esta función es opcional, ten en cuenta los siguientes límites técnicos:

  • Tipo de archivo: Solo PDF.
  • Tamaño máximo del archivo: 50 MB por archivo
  • Límite de cantidad: Hasta 5 documentos únicos. Evita duplicar archivos.

7 de enero de 2026

Nuevo

Presentamos nuevos límites de tráfico para los agentes de RCS para empresas promocionales en India.

Límites en la cantidad total de usuarios únicos

Un nuevo límite afecta la cantidad total de usuarios únicos a los que un agente puede enviar mensajes cada 28 días según su reputación. Todos los agentes nuevos comienzan con una reputación baja de forma predeterminada.

Para obtener una explicación detallada de estos nuevos límites de tráfico y otras reglas empresariales, consulta la página Casos de uso y reglas empresariales de los agentes.