Caso De Uso

Avisos de entrega que envía tu sistema

Enviado, en reparto, listo para recoger. Tu propio sistema llama a la API cuando cambia el pedido, y un mensaje sale hacia un cliente.

  • Una llamada a la API por cambio de estado
  • Webhooks de entrega firmados
  • Claves de API por proyecto

Enviado por

Tu sistema de pedidos

MESSALOGYahora

Hola Ana, el pedido [NUMERO] sale hoy a reparto desde [TU TIENDA]. Puedes seguirlo en este enlace: [ENLACE]

Entregado1 segmento, GSM-7

Un pedido, un mensaje por cambio

  1. El pedido se mueve

    Enviado, en reparto, listo para recoger: tu sistema lo registra.
  2. Tu sistema llama a la API

    Una petición, un cliente, sin lista y sin botón de enviar.
  3. El mensaje llega

    Una línea que dice dónde está el pedido de verdad.
  4. El webhook vuelve

    Los eventos de entrega llegan firmados a tu endpoint.

Dónde está el pedido, en la pantalla que ya tienen en la mano

Un aviso de entrega se lee una vez y se actúa, o no valía la pena mandarlo. Tiene que llegar sin aplicación, sin cuenta y sin iniciar sesión.

Un primer pedido no trae aplicación

Nada que instalar, nada donde entrar, ninguna pestaña en la que el aviso espere a que lo encuentren. Llega al mismo teléfono desde el que se hizo la compra.

Un dato, y qué hacer con él

Enviado, en reparto hoy, listo para recoger, entrega fallida. Acorta el enlace de seguimiento y los clics se cuentan. Son los mismos avisos que manda un transportista: mira logística y reparto.

Esta es la vía transaccional

Un mensaje para un cliente, enviado por tu sistema cuando cambia el estado. Los avisos generales que lo rodean, un almacén cerrado o una fecha límite antes de un festivo, van por la otra vía: una campaña programada. Las dos gastan el mismo saldo de la organización.

Una integración, no un asistente de campaña

Cuatro pasos entre un cambio de estado en tu sistema y un cliente que ya lo sabe.

  1. Crea una clave para el proyecto

    Las claves se crean, se listan y se revocan desde la aplicación, cada una con ámbito de un solo proyecto y, si quieres, restringida a una lista de IP. Empieza por la API para desarrolladores y sigue por claves y accesos.

  2. Llama al envío cuando cambie el estado

    Tu sistema manda el destinatario, el remitente y el texto al endpoint transaccional. Cada mensaje se normaliza, se cuentan sus segmentos y se calcula su precio según el país de destino antes de que salga nada.

  3. Apunta un webhook a tu endpoint

    Cada clave lleva su URL de webhook y su secreto, y los eventos de entrega vuelven firmados y se pueden recibir dos veces sin romper nada. La ficha del pedido se entera de qué fue del mensaje sin que nadie abra la aplicación.

  4. Lee el mismo informe que una campaña

    Los mensajes enviados por la API aparecen en la aplicación como cualquier otro, así que quien atiende al cliente ve qué recibió. Entregas, fallos y el registro por destinatario están en informes.

La audiencia es el pedido

Aquí no hay un segmento que mantener al día ni una lista que importar la noche antes. El destinatario no se elige: es quien hizo el pedido del que habla el mensaje, y tu sistema ya sabe qué número es.

Por eso el campo que decide si esto funciona está antes de Messalogy: un teléfono recogido en el checkout en formato internacional, guardado junto al pedido, y el registro de lo que el cliente aceptó al darlo. Acierta con ese campo y la audiencia se resuelve sola, pedido tras pedido.

Datos del contacto y consentimiento de SMS.