Flujo normal del servicio:
1.- Su aplicación solicita el teléfono (y/o email) al usuario para validar una operación.
2.- Su aplicación llama a EnviarOTP: el sistema genera el código y lo envía.
3.- El usuario introduce el código recibido y su aplicación llama a ValidarOTP.
4.- Si el resultado es 1, la operación queda validada.
Requisitos por canal:
Cada canal que incluya en la cascada debe estar disponible en su cuenta:
- SMS: siempre disponible. MENSAJE opcional (por defecto se envía uno estándar con el código); si lo indica debe contener [CODE].
- VOZ: llamada con locución Text-to-Speech que deletrea el código. Requiere un número de voz propio ACTIVO como REMITENTE (solicitado en el panel).
- EMAIL: con DOMINIO propio validado (remitente de su dominio) o sin DOMINIO (sale por el dominio transaccional por defecto del servicio). ASUNTO y MENSAJEEMAIL opcionales.
- WHATSAPP: requiere cuenta WhatsApp Business conectada, IDTELEFONO e IDPLANTILLA de una plantilla de AUTENTICACIÓN aprobada por Meta (el código rellena la variable del body y el botón de copiar código).
- RCS: requiere Agente RCS activo (IDAGENTE) y una plantilla (IDPLANTILLA) que incluya la variable (CODE).
- PUSH: aviso a los dispositivos del usuario final vinculados desde el panel (sección Avisos). El destino es el ALIAS del dispositivo (parámetro REFPUSH o el campo REF del canal).
Cascada de reintento:
El estado de entrega lo notifica cada operador. Si un canal reporta fallo definitivo, el sistema reenvía el MISMO código por el siguiente canal de la lista. Cuando el código se valida (o caduca), la cascada se detiene automáticamente.
Webhook de estados (recomendado, evita el polling):
Si su cuenta tiene configurada una URL de reports (Tus Datos → Configurar Cuenta), cada cambio de estado del código se envía por POST a esa URL con un JSON que incluye Tipo:"OTP", Evento (entregado | leido | reenviado | fallido), idOTP, idEnvio, App, Destinatario/Email, Canal, CanalesFallidos, Fecha, Expira y ReferenciaUsuario (nunca el código). El evento reenviado añade Motivo y el Canal nuevo. Con webhook configurado, ConsultarOTP solo responde cuando la entrega ya está resuelta (o la petición validada/caducada): la integración correcta es webhook + ValidarOTP, sin bucles de consulta.
Seguimiento en el panel:
Cada petición OTP aparece en el panel como una campaña omnicanal de un destinatario, en Envío Omnicanal → Campañas, etiquetada como OTP y con su propio filtro (Solo OTP), con el detalle de canal, entregas y reintentos.
Control antifraude (opcional):
Con ANTIFRAUDE=SI, antes de enviar se consulta el módulo antifraude sobre el destino (DatosTelefono si hay teléfono; DatosEmail si el destino es solo email; se cobra según el catálogo del módulo). La respuesta incluye el objeto Antifraude con el riesgo (0-100) y sus motivos; si el riesgo alcanza ANTIFRAUDEMAXRIESGO el envío se rechaza con Res -16. Útil contra el SMS-pumping y los números recién portados (secuestro de línea).
Anti-abuso:
Por seguridad, un mismo destino admite un máximo de 5 peticiones de envío cada 10 minutos (Res -6 si se supera). El número de intentos de validación se limita con MAXINTENTOS (por defecto 3). Los códigos se almacenan con hash, viajan cifrados en la cola de reintentos (nunca en claro en reposo) y las respuestas nunca los devuelven.
Migración desde la API v5 (peticionotp/validarotp):
La autenticación pasa de Correo/Passwd a Usuario API + API Token (Basic). El envío por defecto sigue siendo SMS y el parámetro MENSAJE con [CODE] se mantiene. Fail2Voice se sustituye por la cascada (añada el canal voz detrás del sms). Los códigos de resultado de ValidarOTP son los mismos que en la v5.
Respuesta de las peticiones:
La mayoría de las funciones disponen de un parámetro denominado 'Resp'. Este parámetro define el formato de la respuesta que se devolverá. Puede ser TXT, JSON o XML. Se recomienda siempre definir este parámetro.