Esta guía reúne ejemplos de aplicación de la API SMS de netelip por sectores y procesos. Son ejemplos de implementación posibles: no son integraciones nativas, funciones específicas de la API ni casos reales de clientes. Se derivan de los usos generales publicados por netelip: confirmaciones de reservas, compras o envíos; notificaciones; ofertas; notas; recordatorios y recepción de SMS cuando la numeración lo permite.

Para el detalle técnico de cada función (envío, estado, recepción y límites), consulta la guía de integración de la API SMS de netelip.

Frontera técnica. La API SMS envía mensajes, devuelve un ID-SMS, permite consultar su estado y puede entregar SMS entrantes por URL en numeraciones compatibles. La lógica del negocio y cualquier IA pertenecen al sistema externo.

Los sectores de esta guía son ejemplos de implementación posibles. No se presentan como integraciones nativas, funciones específicas de la API ni casos reales de clientes.

Regla que no se rompe. El sistema del cliente detecta el evento, obtiene los datos y decide el contenido. La API SMS de netelip transporta el mensaje y devuelve la información técnica documentada.

• Envío mediante una petición HTTPS POST con token, remitente, destino y mensaje.
• Destino en formato internacional, comenzando por 00.
• Remitente con un máximo de 11 caracteres.
• Mensaje con un máximo documentado de 160 caracteres.
• Respuesta XML con ID-SMS y saldo restante cuando la petición es correcta.
• Consulta posterior del estado mediante el ID-SMS: OK, ERROR o PENDING.
• Recepción por URL mediante HTTP POST con date, from, destination y message, únicamente cuando el número lo admite y está configurado.

Condición técnica de la recepción. La recepción de SMS solo puede utilizarse con una numeración compatible y una URL configurada. Comprueba la disponibilidad antes de diseñar el flujo. Aplica a todos los casos de esta guía.

Confirmaciones y avisos breves alrededor de clases, pruebas y sesiones.

• Confirmar que una solicitud de clase de prueba ha quedado registrada.
• Recordar una clase o sesión desde el sistema de gestión.
• Comunicar un cambio de horario o un cierre especial.

Una respuesta como “CONFIRMO” o “CANCELAR” puede llegar a la URL configurada. Interpretarla y modificar la plaza corresponde al software del gimnasio.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Mensajes vinculados a una solicitud que ya existe en el sistema de gestión.

• Confirmar que una solicitud de taxi ha sido recibida.
• Comunicar los datos de recogida que proporcione el sistema de flota.
• Avisar de un cambio o cancelación registrado por la empresa.

Si existe recepción compatible, el sistema puede recibir una respuesta breve. La API no interpreta “CANCELAR” ni actualiza la solicitud.

• La API no asigna taxis, no calcula rutas y no confirma disponibilidad por sí sola.
• Solo debe comunicarse información obtenida del sistema de gestión.
• No se documenta programación de mensajes desde la API.

Seguimiento operativo de contactos y visitas ya gestionados por la agencia.

• Confirmar una visita agendada en el CRM o software inmobiliario.
• Recordar la fecha, la hora y la referencia de un inmueble.
• Enviar una nota de seguimiento después de registrar una solicitud.

Una respuesta entrante puede entregarse a la aplicación. El CRM debe asociarla al contacto y decidir la acción posterior.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Comunicaciones administrativas sobre citas, sin diagnóstico ni asesoramiento clínico.

• Confirmar una cita registrada por el centro.
• Enviar un recordatorio administrativo.
• Comunicar un cambio de hora o de ubicación.

Con numeración compatible, una respuesta puede llegar a la URL. El sistema sanitario debe identificarla y decidir si confirma, cancela o deriva el caso.

• El SMS debe limitarse a información administrativa definida por el centro.
• La API no diagnostica, prioriza síntomas ni accede a una historia clínica.
• La gestión de datos y del cumplimiento aplicable pertenece al cliente.

Confirmaciones y cambios de reservas registrados en la herramienta del establecimiento.

• Confirmar una reserva.
• Recordar fecha, hora y número de personas.
• Comunicar un cambio registrado por el restaurante.

Si se admite recepción, el cliente puede responder. La aplicación externa debe interpretar la respuesta y actualizar o no la reserva.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Mensajes breves ligados a reservas y eventos registrados durante la estancia.

• Confirmar una reserva.
• Enviar información previa a la llegada facilitada por el alojamiento.
• Comunicar un aviso relacionado con una estancia existente.

Una respuesta puede entregarse por URL si el número es compatible. Gestionar una petición de cambio o una solicitud especial corresponde al alojamiento.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Confirmaciones de cita y avisos basados en el estado registrado por el taller.

• Confirmar una cita de taller.
• Avisar de un cambio de hora.
• Comunicar que un vehículo figura como disponible en el sistema.

Una respuesta entrante puede llegar al sistema externo. La API no acepta presupuestos ni cambia el estado de la orden.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Mensajes transaccionales ligados a compras y pedidos existentes.

• Confirmar una compra registrada.
• Comunicar un cambio de estado facilitado por la plataforma.
• Confirmar que una solicitud de devolución o incidencia ha quedado registrada.

Si el flujo permite respuestas, la aplicación puede recibirlas por URL con numeración compatible y decidir cómo registrar la incidencia.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Avisos creados a partir de eventos confirmados por el sistema logístico.

• Informar de una entrega prevista comunicada por el operador.
• Avisar de un intento de entrega registrado.
• Comunicar que un envío está disponible para recogida.

Una respuesta puede entregarse a la URL configurada. Cambiar la entrega o elegir una franja requiere lógica e integración externa.

• La API no conoce la ubicación del paquete ni la hora real de llegada.
• Solo debe enviarse información obtenida del sistema logístico.
• Los estados OK, ERROR y PENDING se refieren al SMS, no al envío físico.

Confirmación de avisos y comunicaciones breves sobre incidencias registradas.

• Confirmar que un aviso se ha registrado.
• Comunicar una actualización facilitada por el sistema.
• Enviar una notificación especial definida por la administración.

Una respuesta puede llegar a la URL del cliente si existe numeración compatible. Clasificarla y vincularla al expediente corresponde al sistema externo.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Recordatorios y avisos relacionados con clases y convocatorias ya definidas.

• Recordar una clase o tutoría.
• Comunicar un cambio de horario o aula.
• Enviar una convocatoria registrada por el centro.

Si se configura recepción, el sistema puede recibir una respuesta breve. Registrar asistencia o modificar una clase no lo realiza la API.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

Confirmaciones de visitas y cambios gestionados por la aplicación de operaciones.

• Confirmar una visita técnica.
• Recordar una franja prevista.
• Comunicar un cambio registrado por el equipo de operaciones.

Una respuesta recibida por URL puede incorporarse al sistema. Reprogramar o cancelar la visita depende del flujo externo.

• La API no administra el proceso del sector ni decide cuándo debe enviarse el mensaje.
• La programación temporal, si se necesita, debe resolverla el sistema externo; la API pública no documenta programación de envíos.
• La consulta del estado requiere guardar el ID-SMS y consultar el endpoint documentado.

La API SMS no incluye un modelo de IA ni interpreta conversaciones. Puede utilizarse como canal de salida o entrada dentro de una arquitectura externa que sí emplee IA. Para documentarlo con rigor hay que separar las capas.

Punto clave. El SMS debe basarse en el dato confirmado por el sistema. La API no valida si una cita existe ni si la información generada por otro componente es correcta.

Un sistema externo podría utilizar IA para proponer o adaptar un mensaje. Antes del envío, la aplicación debe convertir ese resultado en un texto válido, definir remitente y destino y comprobar que no supera los 160 caracteres. La API recibe el texto final; no sabe cómo se ha generado.

• Guía de integración de la API SMS de netelip
• Documentación técnica: API SMS v1.0
• Centro de ayuda: Configuración del servicio de SMS