Cómo determinar si un número de teléfono aún pertenece a alguien con la API de Twilio Lookup

Cómo determinar si un número de teléfono aún pertenece a alguien con la API de Twilio Lookup

Para cumplir con la Ley de Protección al Consumidor Telefónico (TCPA), debes tener el consentimiento para comunicarte con las personas desde tu aplicación. Un desafío común que puede dar lugar a violaciones de la TCPA ocurre si se ha reasignado un número de teléfono que solía pertenecer a alguien que proporcionó el consentimiento. Es posible que hayas obtenido el consentimiento para el número de teléfono, pero dado que ya no está vinculado a la misma persona, no tienes consentimiento para comunicarte con su nuevo propietario.

La API de Lookup de Twilio proporciona una forma determinista de verificar si se reasignó un número de teléfono para ayudarte a mejorar las tasas de contacto, aumentar la eficiencia de la campaña y evitar multas de cumplimiento. Esta función es especialmente útil para las notificaciones de marketing.

Cómo configurar y utilizar la API de Twilio Lookup para números reasignados

Los requisitos previos para utilizar la API de Lookup incluyen:

1. Una cuenta de Twilio: regístrate hoy mismo.
2. Credenciales de prueba de Twilio: encuéntralas en la página de tokens de autenticación de Console.
3. Para el uso en producción, necesitarás aprobación adicional para utilizar el paquete de datos de números reasignados. Las aprobaciones generalmente tardan entre 2 y 4 días hábiles. Nota: Podrás utilizar la API de inmediato en desarrollo con credenciales de prueba.

Para este tutorial, llamarás a la API de Lookup con credenciales de prueba para tener una respuesta determinista que represente números reasignados.

Además del número de teléfono, la solicitud de API requiere dos parámetros:

1. Fields: reassigned_number. La API de Lookup tiene muchos paquetes de datos que se especifican en el parámetro Fields. Consulta otros.
2. LastVerifiedDate. Con el formato AAAAMMDD, esta es la fecha en que obtuviste el consentimiento para comunicarte con el usuario final, la última vez que te comunicaste con el usuario final o la última vez que el usuario final actualizó su número de teléfono en tu aplicación.

Una vez que tengas tus credenciales de prueba a la mano. Úsalas para reemplazar las credenciales en la siguiente solicitud. Consulta la documentación sobre cómo realizar la misma solicitud mediante Node.js, Python y más idiomas.

Esto devuelve un número reasignado en la respuesta. Verás varias otras claves en la respuesta que pueden ser null, como sim_swap o line_type_intelligence. Esto se debe a que puedes solicitar varios paquetes de datos con el parámetro Fields. Lookup también devolverá la información de validación y formato de forma predeterminada.

Ten en cuenta que el campo is_number_reassigned no es una respuesta booleana, pero puede ser una de las tres opciones:

1. yes. El número de teléfono se ha reasignado desde la última fecha verificada y debes encontrar otra forma de comunicarte con el usuario para volver a solicitar su número de teléfono y su consentimiento para comunicarte con él.
2. no. El número de teléfono aún pertenece al usuario final. Esta respuesta indica un puerto seguro contra violaciones de TCPA con prueba de consentimiento.
3. no_data_available. Por lo general, significa que tu LastVerifiedDate es anterior a enero de 2021 y que debes volver a solicitar el consentimiento para comunicarte.

Para obtener respuestas adicionales, prueba otros números mágicos para probar Lookup.

Cómo funcionan la base de datos de FCC y el"puerto seguro"

Twilio utiliza la base de datos oficial mantenida por la Comisión Federal de Comunicaciones (FCC). Esta base de datos se actualiza mensualmente el día 16 de cada mes. Para los clientes que necesitan validar el estado de reasignación de números más de una vez al mes, recomendamos actualizar tu base de datos el día 17 de cada mes. Los datos obtenidos el día 17 del mes seguirán siendo válidos hasta que la base de datos se actualice nuevamente el día 16 del mes siguiente. Si por algún motivo hay un problema con la base de datos, la FCC ha indicado que la persona que llama puede estar protegida de la responsabilidad si cuenta con la documentación adecuada.

La regla de antigüedad de 45 días

Para resolver cualquier retraso en los informes, la FCC implementó un período de antigüedad obligatorio de 45 días. Los proveedores de servicios tienen prohibido reasignar un número desconectado a un nuevo usuario durante al menos 45 días.

Debido a que los proveedores deben informar las desconexiones antes del día 15 de cada mes, esta ventana de 45 días garantiza un margen para ti como persona que llama. Por ejemplo:

• Día 1: un cliente desconecta su número.

• Día 15: el proveedor informa esta desconexión a la FCC.

• Día 16: la base de datos se actualiza.

• Día 45 en adelante: solo ahora se puede asignar legalmente el número a una nueva persona "incorrecta".

Puerto seguro

Una respuesta negativa de la API de números reasignados de Lookup garantiza el cumplimiento de la TCPA y proporciona pruebas (2 y 3 a continuación) del puerto seguro, según lo define la FCC:

Para protegerse de la responsabilidad en virtud de la TCPA, la persona que llama debe demostrar que: (1) obtuvo el consentimiento del destinatario de la llamada previsto; (2) ella o su agente debidamente autorizado verificaron la base de datos antes de llamar al número para verificar que el número no se había desconectado o reasignado permanentemente después de la fecha en que la persona que llama obtuvo el consentimiento; y (3) la base de datos devolvió una respuesta de consulta de "no" que era incorrecta.

La FCC reconoce que ninguna base de datos es en tiempo real. El puerto seguro es tu protección legal para realizar la "diligencia debida" de verificar la fuente oficial. Ten en cuenta que sigues siendo responsable de demostrar el consentimiento para llamar al destinatario previsto.

Depuración de códigos de error comunes

Cuando la API encuentre un error, verás el código de error anidado dentro de la clave de respuesta reassigned_number. La respuesta aún contendrá un código de estado 200 porque puede solicitar varios paquetes de Lookup en una solicitud determinada y algunos de ellos pueden tener éxito.

Hay cuatro errores comunes que puedes encontrar:

• 60606: el paquete no está habilitado. Mientras tanto, solicita acceso mediante este formulario y prueba con credenciales de prueba y números mágicos.
• 60607: solicitud de un número de teléfono fuera de los EE. UU. Los números reasignados solo se admiten para EE. UU.
• 60617: falta LastVerifiedDate.
• 60618: LastVerifiedDate no tiene el formato correcto. El formato correcto es AAAAMMDD. Elimina todos los guiones o espacios.

Cómo llevar la detección de números reasignados a producción

El cumplimiento de los mensajes de marketing es esencial y detectar los números reasignados te ayudará a evitar multas. Ten en cuenta que Twilio no mantiene una lista de personas a las que no se debe llamar, por lo que te recomendamos que utilices los números reasignados de Lookup con la lista nacional de personas las que no se debe llamar para determinar el consentimiento para comunicarte con tu base de usuarios. Una vez que estés listo para ejecutar tu aplicación en producción, asegúrate de tener la aprobación del operador móvil y comienza a hacer solicitudes con tus claves de API de producción en lugar de tus credenciales de prueba.

Una vez que estés preparado para detectar números reasignados, prueba otros paquetes de datos de Lookup con Code Exchange, incluida la detección de números VoIP con Line Type Intelligence o la búsqueda de un número de teléfono con intercambio de SIM antes de enviar una solicitud de SMS 2FA. Luego, puedes integrar la API de Verify para probar la posesión del número de teléfono y completar el trayecto de verificación del usuario. ¡Estoy ansiosa por ver lo que eres capaz de crear y proteger!