Verificação por e-mail e SMS para agentes de IA

A verificação se divide mais ou menos ao meio. Ferramentas para desenvolvedores e SaaS costumam enviar um código por e-mail. Tudo o que envolve dinheiro, identidade ou uma conta atrelada a um telefone envia um SMS. Um agente que só consegue fazer um dos dois trava em metade da internet.

A resposta de sempre são dois fornecedores: uma API de e-mail e uma API de SMS. São dois modelos de autenticação, dois formatos de resposta, duas estratégias de polling, dois modos de falha e uma pilha de código de cola cujo único trabalho é fazer os dois parecerem iguais para o agente. A cola é o problema: é a parte que ninguém quer manter e que todo mundo tem que escrever.

O mesmo formato, nos dois canais

O apumail passa os dois por uma única camada. O fluxo de e-mail:

# provision an inbox — no auth
INBOX=$(curl -sS -X POST https://api.apumail.com/api/v1/inboxes)
ADDR=$(echo "$INBOX" | jq -r .address)
TOK=$(echo "$INBOX" | jq -r .token)

# block until it lands, read the extracted code
curl -sS -H "Authorization: Bearer $TOK" \
  "https://api.apumail.com/api/v1/inbox/$ADDR/wait?timeout=120" \
  | jq -r '.messages[0].otp'

E o fluxo de SMS:

# buy a real dedicated number, on demand
PHONE=$(curl -sS -X POST https://api.apumail.com/api/v1/phones \
  -H "Authorization: Bearer $TOK" \
  -d '{"country_code":"US"}')

# same wait, same extract, different channel

Criar, esperar, extrair. Os mesmos verbos, a mesma autenticação, o mesmo JSON. No MCP a simetria é literal: wait_for_mail / extract_latest_otp ao lado de wait_for_sms / extract_latest_sms_otp. Um agente que aprendeu um aprendeu o outro.

Números sob demanda

O que torna o SMS para agentes desajeitado em outros lugares é a aquisição. A maioria dos fluxos pressupõe um humano: escolher um número de um pool, esperar disponibilidade, mandar e-mail ao suporte para uma região nova. Um único POST /api/v1/phones com um country_code compra um número dedicado real na hora: sem pool para esperar, sem humano para quem escrever. É o número do agente enquanto estiver pago, não um compartilhado em que caem os códigos de outra pessoa.

Essa também é a contrapartida honesta: é um plano pago. Um número custa a partir de $20/ano nos EUA/Canadá, com preço por país ($16 em $PROWL), e enviar custa $0.07/SMS a partir de crédito pré-pago. Caixas de e-mail são gratuitas; números de telefone custam dinheiro porque as operadoras cobram. Se você só precisa de códigos por e-mail, nunca encosta nisso e nunca paga.

Enviar, não só receber

Os dois canais são bidirecionais, e isso importa mais do que parece. A verificação nem sempre é um código: às vezes é responder para confirmar, e às vezes o fluxo que você está automatizando continua pelo mesmo canal depois do código. Um agente que só consegue receber tem que passar a vez para um humano na primeira resposta. send_mail e send_sms o mantêm no loop, com o from travado no endereço ou número do próprio agente, para que um token vazado não sirva para se passar por ninguém.

Onde isso te deixa

Um único fornecedor para um problema que costuma ser duplo não é uma virtude por si só: é uma virtude quando as duas metades de fato compartilham o formato, e aqui compartilham. Comece pelo fluxo de e-mail, que é gratuito e exige um único POST. Adicione um número quando algum fluxo exigir.