---
title: "Configurações de verificação"
description: "Defina por quanto tempo os códigos do Verify permanecem válidos, quantas checagens erradas fazem uma verificação falhar, o intervalo de espera para reenvio e o site em que os códigos são preenchidos automaticamente."
canonical: "https://bird.com/pt-br/documentacao/guides/verify/settings"
---

# Configurações de verificação

A aba **General** da página [**Configure**](https://bird.com/dashboard/w/verify/configure) define como cada verificação do seu espaço de trabalho se comporta. Ela controla por quanto tempo um código permanece válido, quantas tentativas erradas encerram uma verificação, quanto tempo depois um novo código pode ser enviado e a qual site o código pertence.

Cada campo mostra o valor efetivo: a sua substituição, quando você definiu uma, ou então o padrão da plataforma da Bird. Um campo é salvo quando você sai dele. **Duration**, **Maximum Retries** e **Website** são fixados quando uma verificação é criada, então uma alteração neles vale para novas verificações. Uma alteração em **Retry Delay** vale para a próxima chamada de criação, inclusive para uma verificação já em andamento.

Para alterar uma configuração, é preciso ter a permissão `verify_management` no nível `write`, incluída nas funções `admin` e `developer`. A função `analyst` pode visualizar a página. Consulte [Usuários, equipes e funções](/docs/guides/users-teams-roles#workspace-roles).

![A aba General da página Configure com os campos Duration, Maximum Retries, Retry Delay e Website](/images/docs/dashboard-verify-configure-general.png)

## Ciclo da verificação

| Configuração        | O que controla                                                                                                                                                     | Padrão      | Intervalo             |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | --------------------- |
| **Duration**        | Por quanto tempo uma verificação fica aberta. Uma checagem feita após esse período retorna o motivo `expired`, e a verificação termina com o motivo `ttl_elapsed`. | 10 minutos  | De 1 a 999 minutos    |
| **Maximum Retries** | Quantos códigos incorretos encerram uma verificação. O último faz a verificação falhar com o motivo `attempts_exhausted`.                                          | 5           | De 1 a 10             |
| **Retry Delay**     | O intervalo de reenvio: a espera mínima antes que outro código seja enviado ao mesmo destinatário.                                                                 | 60 segundos | De 0 a 3.600 segundos |

- A **Duration** começa a contar quando a verificação é criada. Um reenvio ou uma troca para outro canal envia um novo código, mas mantém a expiração original, então um reenvio tardio não estende a janela. Para fluxos de autenticação, mantenha o valor em 10 minutos ou menos; [Best practices](/docs/guides/verify/best-practices#keep-the-lifetime-at-ten-minutes-or-less) explica o motivo.
- **Maximum Retries** conta os códigos errados de todos os códigos enviados para a verificação, então um reenvio não zera essa contagem. Uma checagem com um código errado que deixa a verificação pendente informa as tentativas restantes em `attempts_remaining`.
- **Retry Delay** se aplica quando você chama a criação novamente para o mesmo destinatário. Durante o intervalo de espera, a chamada retorna a verificação ativa sem enviar um novo código. [Enviar o código por outro canal](/docs/guides/verify/sending-verifications#send-the-code-on-another-channel) é uma exceção, porque trocar de canal é uma solicitação diferente de pedir o mesmo canal de novo. Defina o valor como 0 para enviar um novo código a cada chamada de criação, dentro dos limites por destinatário descritos em [Abuse guardrails](/docs/guides/verify/sending-verifications#abuse-guardrails).

O tamanho do código não fica nesta página. Por padrão, os códigos têm seis dígitos numéricos, e `options.code_length` define de 4 a 8 dígitos para uma verificação; consulte [Options](/docs/guides/verify/sending-verifications#options).

## Preenchimento automático

**Website** indica o site onde seus usuários digitam os códigos, como `https://login.example.com`. Com um site definido, os navegadores podem oferecer o código nesse site e em nenhum outro, o que poupa o usuário de copiá-lo. Deixe o campo vazio para enviar códigos que não indicam nenhum site.

Escreva o site como `https://` seguido do domínio em letras minúsculas, sem porta, caminho ou barra final. Um domínio internacionalizado usa a forma `xn--`, por exemplo `https://xn--bcher-kva.example` para `bücher.example`. Qualquer outra forma é rejeitada, e a mensagem indica a forma correta quando ela existe. Use exatamente o site que exibe o campo do código: um formulário em `login.example.com` precisa de `https://login.example.com`, e não de `https://example.com`.

Quando uma verificação tem um site, o Verify o adiciona às mensagens com o código:

- **SMS**: a mensagem termina com uma linha como `@login.example.com #123456`. Marque o campo do código com `autocomplete="one-time-code"` para que o Safari e outros navegadores ofereçam o código, e chame a [API WebOTP](https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API) na página se quiser que o navegador o preencha sem um toque. A linha extra pode acrescentar um segmento de SMS. Em muitos idiomas que exigem codificação Unicode, como árabe, grego ou russo, um código vinculado ocupa dois segmentos em vez de um, o que dobra a cobrança de SMS. Um domínio longo pode ter o mesmo efeito em outros idiomas.
- **Email**: a mensagem inclui um cabeçalho `OTP-Token` com o código e o site, conforme definido no [Internet-Draft OTP-Token, revisão 01](https://datatracker.ietf.org/doc/draft-goto-otp-token/01/). Os aplicativos de e-mail estão apenas começando a ler esse cabeçalho, então trate-o como um complemento ao código na mensagem.

O site é fixado quando a verificação é criada. Um reenvio, um fallback para outro canal ou outra chamada de criação para o mesmo destinatário mantém esse site.

### Vincular um código por solicitação

Uma solicitação pode definir o próprio site com `options.autofill_origin`, que substitui **Website** para essa verificação. Use essa opção quando um espaço de trabalho atende a vários sites.

Quando o campo do código fica em um iframe de outra origem, como um formulário de pagamento incorporado ao checkout de uma loja, defina `options.autofill_origin` como o site do iframe e `options.autofill_top_level_origin` como a página aberta na aba do navegador. A linha SMS passa então a indicar os dois sites, como em `@shop.example #123456 @pay.example`, o que pode acrescentar um segmento em qualquer idioma. O Chrome preenche automaticamente esse formulário quando a página incorpora o iframe diretamente e concede a ele `allow="otp-credentials"`. O e-mail não envia o cabeçalho `OTP-Token` nessas verificações, porque o cabeçalho só pode indicar um site. A solicitação é rejeitada com `422` quando o site de nível superior está malformado, quando nenhum site está definido na solicitação nem nesta página, ou quando ele é igual a esse site.

### Remetentes SMS registrados

Se você envia SMS pelo seu próprio remetente registrado, como uma campanha 10DLC nos EUA, adicione à campanha uma mensagem de exemplo que termine com a linha vinculada antes de definir um site. As operadoras podem filtrar uma mensagem diferente dos exemplos registrados na campanha.

## Solução de problemas

- **O site é rejeitado.** O valor não está no formato exigido. Informe o formato sugerido na mensagem, por exemplo `https://example.com` para `https://Example.com/`.
- **O navegador não oferece o código.** Verifique se o site corresponde exatamente ao endereço da página, incluindo qualquer subdomínio, e se o campo do código tem `autocomplete="one-time-code"`. Para um iframe, verifique se a solicitação define os dois sites e se a página que o incorpora concede `allow="otp-credentials"`. O preenchimento automático também depende do navegador: o Chrome lê a linha SMS pelo WebOTP e o Safari pelo seu preenchimento automático de códigos, enquanto o Firefox não oferece suporte ao WebOTP ([suporte dos navegadores](https://caniuse.com/mdn-api_otpcredential)).
- **Um código expirou antes de o usuário digitá-lo.** Confira o tempo das tentativas no [log do Verify](/docs/guides/verify/verify-log) antes de aumentar **Duration**. Normalmente a causa é uma rota de entrega lenta, e uma janela mais longa enfraquece o código.

## Próximos passos

- [Envio de verificações](/docs/guides/verify/sending-verifications): crie e confira verificações, incluindo opções por solicitação.
- [Destinos](/docs/guides/verify/destinations): escolha os canais e a ordem deles para cada país de destino.
- [Remetentes e identidade visual](/docs/guides/verify/senders): veja as mensagens que o Verify envia e escolha o remetente 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)
