Dê ao seu agente de IA um endereço de e-mail em uma chamada

Um agente de IA consegue se cadastrar num serviço, disparar um job ou abrir um chamado de suporte, e aí o fluxo para, porque a resposta chega num lugar onde o agente não existe: uma caixa de entrada de e-mail. Códigos de verificação, recibos, avisos de "sua exportação está pronta", redefinições de senha. O e-mail é o mecanismo de callback mais antigo da internet, e agentes não têm endereço.

Este post mostra a menor solução que conseguimos construir. Uma chamada de API, sem cadastro, devolve um endereço de e-mail que funciona e cujas mensagens recebidas viram eventos estruturados que o agente lê de volta por HTTP, no mesmo log de eventos em que caem seus webhooks.

TL;DR

POST https://anyhook.net/api/v1/quickstart (sem autenticação) devolve o campo inbox_address, com um endereço como q-cd3fe0f8.quickstart@anyhook.net, além do campo inbound_url, para webhooks, e uma chave de API
O e-mail enviado para esse endereço vira um evento email.received: from, to, subject, message_id e a mensagem MIME bruta completa
O agente lista os eventos com GET /api/v1/events e lê um deles com GET /api/v1/events/{id}, ou pelo MCP com anyhook_inbox / anyhook_events / anyhook_inspect (registro: net.anyhook/anyhook, endpoint remoto https://anyhook.net/mcp)
Ele só recebe. Não envia nem responde, e esse é um limite proposital, não uma lacuna no roadmap
Endpoints gratuitos expiram em 7 dias se você não os vincular à sua conta; o plano Free tem limite de 1.000 eventos/dia

A única chamada

curl -X POST https://anyhook.net/api/v1/quickstart

{
  "inbound_url": "https://in.anyhook.net/q-cd3fe0f8/quickstart",
  "inbox_address": "q-cd3fe0f8.quickstart@anyhook.net",
  "api_key": "ahk_live_…",
  "claim_url": "https://anyhook.net/claim/…",
  "expires_at": "2026-08-06T…"
}

Você não cria conta, não resolve captcha nem passa por uma tela de consentimento OAuth. Isso importa porque, aqui, quem chama muitas vezes não é uma pessoa. É um agente no meio de uma tarefa, e cada formulário de cadastro no caminho é um ponto onde a tarefa morre. O endpoint é efêmero (7 dias) até que um humano o vincule a uma conta pelo campo claim_url, e esse também é o teto contra abuso: nada anônimo sobrevive ao próprio TTL.

O mesmo app agora responde em dois transportes:

Transporte	Endereço
Webhook HTTP	`https://in.anyhook.net/q-cd3fe0f8/quickstart`
E-mail	`q-cd3fe0f8.quickstart@anyhook.net`

Os dois alimentam um único log de eventos, então "esperar o webhook da Stripe" e "esperar o e-mail de confirmação" são a mesma operação do lado do agente: fazer polling na API de eventos e inspecionar o payload.

No que um e-mail se transforma

Envie qualquer e-mail para o endereço. Em segundos, ele aparece como um evento:

{
  "type": "email.received",
  "from": "noreply@github.com",
  "to": "q-cd3fe0f8.quickstart@anyhook.net",
  "subject": "Your verification code is 481920",
  "message_id": "<abc123@mail.example.com>",
  "date": "Thu, 30 Jul 2026 11:42:31 +0700",
  "size": 7026,
  "raw": "Received: from …"
}

O campo raw é a mensagem MIME completa e sem modificações: todos os cabeçalhos, todas as partes, todos os anexos, exatamente como chegaram. Os campos de metadados são atalhos; a mensagem bruta é a fonte da verdade. No caso mais comum para agentes, tirar um código de um e-mail de verificação, a linha de assunto sozinha costuma bastar. Para qualquer coisa mais elaborada, faça o parse do MIME com a biblioteca padrão da sua linguagem. É para isso que ela existe.

Para ler de volta:

curl https://anyhook.net/api/v1/events \
  -H "Authorization: Bearer ahk_live_…"

# the list carries no payloads; this returns one event with its body
curl https://anyhook.net/api/v1/events/<id> \
  -H "Authorization: Bearer ahk_live_…"

O mesmo formato de um endpoint de webhook: criar primeiro, vincular a uma conta depois. A caixa de entrada é só uma porta da frente diferente.

Pelo MCP

Se o agente fala MCP, ele nunca encosta no curl. O servidor está listado no registro oficial de MCP como net.anyhook/anyhook, na forma do pacote npm anyhook-mcp e de um endpoint remoto streamable HTTP em https://anyhook.net/mcp:

anyhook_quickstart devolve o campo inbox_address diretamente (no pacote npm, roda sem chave; o endpoint remoto precisa antes de uma chave de API ou de um login)
anyhook_inbox devolve o endereço de um app existente, mais a URL de webhook dele
anyhook_events / anyhook_inspect leem o que chegou

A ferramenta de início rápido é todo o onboarding. Um agente que descobre o servidor num registro consegue criar para si uma caixa de entrada e começar a receber sem um humano no processo. O humano entra depois, se é que entra, para vincular a conta.

Como funciona (e por que o endereço tem essa cara)

Por baixo, de propósito, não existe um segundo pipeline:

Um catch-all do Cloudflare Email Routing entrega toda mensagem do domínio ao mesmo Worker na edge que recebe os webhooks
O Worker divide a parte local do endereço no último ponto: {user-slug}.{app-slug}@anyhook.net. Os slugs são sanitizados para [a-z0-9-] na criação, então nunca podem conter ponto, o que torna a divisão inequívoca por construção
A mensagem é reempacotada como a requisição HTTP que teria sido, e tudo o que vem depois segue exatamente o mesmo caminho de código dos webhooks: cota, limites de payload, fila, novas tentativas (retries), entrega aos seus destinos, o log de eventos

Um e-mail que não corresponde a um app real é recusado já na conversa SMTP, e não engolido em silêncio. Um remetente que não recebe erro supõe que houve entrega. Mensagens grandes demais voltam do mesmo jeito.

Duas propriedades vêm de graça do lado dos webhooks. Os corpos das mensagens são criptografados com AES-256-GCM antes de tocar o banco de dados. E o hash de cada evento entra numa cadeia por app que é selada todo dia, com a raiz de cada dia registrada num repositório git público para o qual o AnyHook não tem nenhuma credencial. Se editássemos um e-mail armazenado depois que o dia dele foi selado, as âncoras publicadas deixariam de passar na verificação.

O que isto não é

Não envia. Sem respostas, sem e-mail de saída, sem credenciais SMTP. Enviar é onde moram a entregabilidade, o alinhamento de SPF/DKIM, a reputação de IP e a responsabilidade por spam. É outra disciplina, com outros modos de falha. Se seu agente precisa de e-mail conversacional de mão dupla como produto, essa categoria existe (a AgentMail captou investimento exatamente com essa tese). Uma caixa de entrada que só recebe, acoplada a um relay de webhooks (um serviço que recebe, guarda e encaminha seus webhooks), é algo mais restrito: um único log de eventos para tudo o que chega.

Não é um serviço de e-mail descartável. O uso pretendido é o e-mail que seus próprios sistemas geram: confirmações de contas que seu agente opera legitimamente, notificações de serviços que você integra, recibos dos seus próprios fluxos. Endpoints gratuitos têm rate limit, têm teto de volume e expiram, e padrões de abuso são bloqueados. Se os termos de um serviço proíbem cadastro automatizado, uma caixa de entrada não muda isso.

É polling, não push. O agente pergunta "o que chegou?" e nada o acorda. Quando você precisar de latência menor, configure o campo destination_url e o evento é encaminhado para seu próprio servidor assim que chega. O e-mail vira um webhook.

Teste

# 1. mint an inbox (no signup)
curl -X POST https://anyhook.net/api/v1/quickstart

# 2. send any email to the inbox_address you got back

# 3. find it, then read it
curl https://anyhook.net/api/v1/events -H "Authorization: Bearer <api_key>"
curl https://anyhook.net/api/v1/events/<id> -H "Authorization: Bearer <api_key>"

O tempo total de configuração é o tempo que o e-mail do passo 2 leva para chegar.