--- title: "Configuración de verificación" description: "Define cuánto tiempo siguen siendo válidos los códigos de Verify, cuántas comprobaciones incorrectas hacen fallar una verificación, el tiempo de espera entre reenvíos y el sitio web en el que se autocompletan los códigos." canonical: "https://bird.com/es-es/documentacion/guides/verify/settings" --- # Configuración de verificación La pestaña **General** de la página [**Configure**](https://bird.com/dashboard/w/verify/configure) define cómo se comporta cada verificación de tu espacio de trabajo. Controla cuánto tiempo sigue siendo válido un código, cuántos intentos incorrectos terminan una verificación, cuánto hay que esperar para enviar un código nuevo y a qué sitio web pertenece el código. Cada campo muestra el valor efectivo: tu valor personalizado si lo has definido o, si no, el valor predeterminado de la plataforma de Bird. Un campo se guarda al salir de él. **Duration**, **Maximum Retries** y **Website** quedan fijados al crear una verificación, así que un cambio en ellos se aplica a las verificaciones nuevas. Un cambio en **Retry Delay** se aplica a la siguiente llamada de creación, también para una verificación que ya está en curso. Para cambiar una opción necesitas el permiso `verify_management` en el nivel `write`, que incluyen los roles `admin` y `developer`. El rol `analyst` puede ver la página. Consulta [Usuarios, equipos y roles](/docs/guides/users-teams-roles#workspace-roles). ![La pestaña General de la página Configure con los campos Duration, Maximum Retries, Retry Delay y Website](/images/docs/dashboard-verify-configure-general.png) ## Ciclo de verificación | Opción | Qué controla | Valor predeterminado | Rango | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | -------------------- | | **Duration** | Cuánto tiempo permanece abierta una verificación. Una comprobación fuera de este plazo devuelve el motivo `expired`, y la verificación termina con el motivo `ttl_elapsed`. | 10 minutos | De 1 a 999 minutos | | **Maximum Retries** | Cuántos códigos incorrectos terminan una verificación. El último la hace fallar con el motivo `attempts_exhausted`. | 5 | De 1 a 10 | | **Retry Delay** | El tiempo de espera entre reenvíos: la espera mínima antes de enviar otro código al mismo destinatario. | 60 segundos | De 0 a 3600 segundos | - **Duration** empieza a contar cuando se crea la verificación. Un reenvío o un cambio a otro canal envía un código nuevo, pero mantiene la caducidad original, así que un reenvío tardío no amplía el plazo. Mantenlo en 10 minutos o menos en los flujos de autenticación; [Buenas prácticas](/docs/guides/verify/best-practices#keep-the-lifetime-at-ten-minutes-or-less) explica por qué. - **Maximum Retries** cuenta los códigos incorrectos de todos los códigos enviados para la verificación, así que un reenvío no lo reinicia. Si una comprobación con un código incorrecto deja la verificación pendiente, indica los intentos restantes en `attempts_remaining`. - **Retry Delay** se aplica cuando vuelves a llamar a create para el mismo destinatario. Durante el tiempo de espera, la llamada devuelve la verificación activa sin enviar un código nuevo. [Enviar el código por otro canal](/docs/guides/verify/sending-verifications#send-the-code-on-another-channel) queda exento, porque cambiar de canal es una solicitud distinta de pedir de nuevo el mismo canal. Ponlo en 0 para enviar un código nuevo en cada llamada a create, dentro de los límites por destinatario de [Protecciones contra abusos](/docs/guides/verify/sending-verifications#abuse-guardrails). La longitud del código no está en esta página. Por defecto, los códigos tienen seis dígitos numéricos, y `options.code_length` fija entre 4 y 8 dígitos para una verificación; consulta [Opciones](/docs/guides/verify/sending-verifications#options). ## Autocompletado **Website** indica el sitio donde tus usuarios introducen sus códigos, como `https://login.example.com`. Con un sitio web configurado, los navegadores pueden ofrecer el código en ese sitio y en ningún otro, lo que evita que el usuario tenga que copiarlo. Déjalo vacío para enviar códigos que no indiquen ningún sitio web. Escribe el sitio web como `https://` seguido de su dominio en minúsculas, sin puerto, ruta ni barra final. Un dominio internacionalizado usa su forma `xn--`, por ejemplo `https://xn--bcher-kva.example` para `bücher.example`. Cualquier otra forma se rechaza, y el mensaje indica la forma que debes introducir cuando existe una. Usa el sitio exacto que muestra el campo del código: un formulario en `login.example.com` necesita `https://login.example.com`, no `https://example.com`. Cuando una verificación tiene un sitio web, Verify lo añade a los mensajes con el código: - **SMS**: el mensaje termina con una línea como `@login.example.com #123456`. Marca el campo del código con `autocomplete="one-time-code"` para que Safari y otros navegadores ofrezcan el código, y llama a la [API de WebOTP](https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API) desde la página si quieres que el navegador lo rellene sin que el usuario toque nada. La línea adicional puede añadir un segmento de SMS: en muchos idiomas que necesitan codificación Unicode, como el árabe, el griego o el ruso, un código vinculado ocupa dos segmentos en lugar de uno, lo que duplica su coste de SMS, y un dominio largo puede tener el mismo efecto en otros idiomas. - **Email**: el mensaje incluye una cabecera `OTP-Token` con el código y el sitio web, según define el [Internet-Draft OTP-Token, revisión 01](https://datatracker.ietf.org/doc/draft-goto-otp-token/01/). Las aplicaciones de correo apenas empiezan a leer esta cabecera, así que considérala un complemento del código que aparece en el mensaje. El sitio web queda fijado al crear la verificación. Un reenvío, un cambio a otro canal de respaldo u otra llamada a create para el mismo destinatario lo mantienen. ### Vincular un código en cada solicitud Una solicitud puede indicar su propio sitio web con `options.autofill_origin`, que sustituye a **Website** para esa verificación. Úsalo cuando un mismo espacio de trabajo da servicio a varios sitios. Cuando el campo del código está en un iframe de otro origen, como un formulario de pago integrado en el proceso de compra de una tienda, asigna a `options.autofill_origin` el sitio web del iframe y a `options.autofill_top_level_origin` la página que aparece en la pestaña del navegador. Así, la línea de SMS nombra ambos sitios, como en `@shop.example #123456 @pay.example`, lo que puede añadir un segmento en cualquier idioma. Chrome rellena automáticamente ese formulario cuando la página integra el iframe directamente y le concede `allow="otp-credentials"`. El correo electrónico no envía la cabecera `OTP-Token` en estas verificaciones, porque la cabecera solo puede nombrar un sitio web. La solicitud se rechaza con `422` cuando el sitio web de nivel superior tiene un formato incorrecto, cuando no hay ningún sitio web definido en la solicitud ni en esta página, o cuando coincide con ese sitio web. ### Remitentes de SMS registrados Si envías SMS desde tu propio remitente registrado, como una campaña 10DLC de EE. UU., añade a la campaña un mensaje de ejemplo que termine con la línea vinculada antes de configurar un sitio web. Los operadores pueden filtrar un mensaje que no coincida con los ejemplos registrados de la campaña. ## Solución de problemas - **Se rechaza el sitio web.** El valor no tiene el formato requerido. Introduce el formato que sugiere el mensaje, por ejemplo `https://example.com` para `https://Example.com/`. - **El navegador no ofrece el código.** Comprueba que el sitio web coincide exactamente con la dirección de la página, incluido cualquier subdominio, y que el campo del código tiene `autocomplete="one-time-code"`. Si usas un iframe, comprueba que la solicitud define ambos sitios web y que la página que lo integra concede `allow="otp-credentials"`. El autorrelleno también depende del navegador: Chrome lee la línea de SMS mediante WebOTP y Safari mediante su autorrelleno de códigos, mientras que Firefox no admite WebOTP ([compatibilidad de navegadores](https://caniuse.com/mdn-api_otpcredential)). - **Un código caducó antes de que el usuario lo introdujera.** Revisa los tiempos de los intentos en el [registro de Verify](/docs/guides/verify/verify-log) antes de aumentar **Duration**. La causa suele ser una ruta de entrega lenta, y un plazo más largo debilita el código. ## Próximos pasos - [Envío de verificaciones](/docs/guides/verify/sending-verifications): crea y comprueba verificaciones, incluidas las opciones por solicitud. - [Destinos](/docs/guides/verify/destinations): elige los canales y su orden para cada país de destino. - [Remitentes y marca](/docs/guides/verify/senders): consulta los mensajes que envía Verify y elige el remitente de cada canal. ## Related resources - [Verify phone numbers at signup](/learn/series/verify-phone-numbers-at-signup) (video) - [What does OTP mean? One-time passwords explained](/explained/verify/what-does-otp-mean) (answer) - [Customer verification](/verify-api) (product) - [Build your first integration](/learn/paths/integration) (course) [Get an implementation brief](/learn/workspace?topic=verify)