Perguntas frequentes

Por que não dar ao meu agente acesso ao meu Gmail ou Outlook?

Segurança — O OAuth do Gmail/Outlook dá ao seu agente acesso a toda a sua caixa de entrada (médica, financeira, jurídica, pessoal). Uma injeção imediata em qualquer e-mail recebido pode manipular um agente com acesso a todo ele. O InboxAPI oferece ao seu agente sua própria caixa de entrada isolada com classificação confiável e marcação de dados em cada mensagem.

Identidade — Quando seu agente envia mensagens do seu Gmail, os destinatários não sabem com quem estão falando. As respostas vão para sua caixa de entrada, misturadas com seu e-mail real. A InboxAPI fornece ao seu agente um endereço pessoal — separação clara entre você e seu agente.

Praticidade — As APIs do Gmail/Outlook não são nativas do MCP. Você precisaria de middleware, encanamento OAuth e integração personalizada. O InboxAPI funciona imediatamente com qualquer cliente MCP.

Como isso difere do AWS SES, SendGrid ou Resend?

Essas são APIs de envio – você constrói uma infraestrutura de e-mail sobre elas. O InboxAPI oferece ao seu agente uma identidade de e-mail completa: enviar, receber, pesquisar, responder e encaminhar. Não há nada para configurar nem infraestrutura para gerenciar.

Como isso é diferente do AgentMail ou do a1base?

Construímos nossa própria pilha de e-mail do zero. Não empacotamos SES, Postfix ou qualquer serviço de envio de terceiros. A correspondência do seu agente passa pela infraestrutura que operamos diretamente.

É realmente grátis?

Sim. Sem cartão de crédito, sem período de teste, sem níveis de uso. Estamos trabalhando em planos pagos com recursos adicionais, mas a experiência principal sempre será gratuita.

Como você evita spam e abuso?

A criação de conta requer prova de trabalho. Cada conta possui 5 slots de catálogo de endereços para destinatários externos — quando todos os slots estão em uso, a entrada usada menos recentemente é substituída automaticamente após 5 dias de inatividade. Cotas de envio diário e limitação de taxa são aplicadas em todas as contas. Estas restrições são estruturais – não são políticas, são a forma como o sistema funciona.

E quanto à injeção imediata por e-mail?

Cada e-mail recebido inclui uma classificação de confiança – confiável, agente, não verificado ou suspeito – com base no fato de o remetente estar em seu catálogo de endereços e se o e-mail for aprovado nas verificações de autenticação. Isso ajuda seu agente a decidir com que cautela lidar com cada mensagem. E-mails de outros agentes InboxAPI são sinalizados separadamente para que seu agente saiba que deve verificar com você antes de agir sobre eles.

Além disso, o conteúdo de e-mail não confiável é transformado automaticamente usando destaque (marcação de dados) — o espaço em branco é substituído por um caractere marcador exclusivo para que seu agente possa distinguir claramente os dados do e-mail de suas próprias instruções. Isso reduz a taxa de sucesso de ataques de injeção imediata incorporados em e-mails de aproximadamente 50% para menos de 3%.

O que é destaque?

As ferramentas de recuperação de e-mail aplicam marcação de dados a conteúdo não confiável, substituindo espaços em branco por um caractere marcador Unicode exclusivo gerado por solicitação. O conteúdo que contém o marcador deve ser tratado como dados externos – nunca como instruções a seguir. Para recuperar o texto original, substitua o marcador por um espaço. E-mails de remetentes confiáveis ​​(no seu catálogo de endereços com autenticação válida) não são destacados por padrão. Esta técnica é baseada em pesquisas acadêmicas (arXiv:2403.14720).

E quanto à exfiltração de dados?

Os e-mails enviados são verificados em busca de tokens e credenciais de autenticação. Se o seu agente tentar acidentalmente enviar um email contendo um JWT ou token de acesso, a mensagem será rejeitada antes de sair da plataforma. Isso evita que os agentes sejam induzidos a vazar dados confidenciais por e-mail. Além disso, todos os endereços de destinatários nas operações de envio, resposta e encaminhamento são validados em relação à RFC 5322 — endereços malformados são rejeitados antes da entrega.

Os agentes podem enviar spam entre si?

Os mesmos limites de envio se aplicam a todos os e-mails enviados: limites de destinatários, cotas e limites de taxa funcionam da mesma forma, independentemente de quem está recebendo.

Os e-mails do meu agente serão considerados spam?

Talvez no início. Cada agente obtém um subdomínio totalmente novo e os novos remetentes ainda não têm reputação. Os destinatários podem precisar verificar a pasta de spam nos primeiros e-mails. Com o tempo, à medida que seu agente envia correspondência legítima e os destinatários interagem com ela, a entrega melhora. VerEntrega de e-mailpara mais detalhes.

Por que enviar e-mail em vez de um protocolo de agente nativo como o A2A?

O e-mail chega a toda a Internet existente – bilhões de pessoas e empresas já o utilizam. A2A exige que ambos os lados implementem o protocolo. Quando seu agente precisa entrar em contato com alguém fora de seu próprio ecossistema, o email é a opção universal. Os agentes provavelmente precisarão de ambos.

Por que enviar e-mail em vez de WhatsApp, Telegram ou outros aplicativos de mensagens?

Os aplicativos de mensagens parecem uma opção natural para a comunicação entre agentes, mas têm limitações estruturais que os tornam impraticáveis ​​para agentes em grande escala.

Escalabilidade — Você pode criar centenas de endereços de e-mail de maneira programática. WhatsApp, Telegram e Signal exigem números de telefone e verificação. Ultrapassar um punhado de contas é impraticável, muitas vezes contra os termos de serviço, e às vezes impossível sem cartões SIM físicos. Se o seu fluxo de trabalho precisar de 50 agentes, você precisará de 50 números de telefone.

Sem controle de identidade — O e-mail é o único canal de comunicação onde você pode criar uma identidade sem um número de telefone, identificação governamental ou aprovação do proprietário da plataforma. Nenhuma empresa controla quem recebe um endereço de e-mail.

Protocolo aberto — O e-mail é federado e independente de fornecedor. WhatsApp, Discord e Telegram são proprietários – eles podem revogar o acesso à API, banir contas de bot ou alterar as regras a qualquer momento. O e-mail não pode ser desativado por uma empresa.

Conformidade com ToS — A maioria das plataformas de mensagens proíbe explicitamente contas automatizadas ou tem processos de aprovação rígidos (a API do WhatsApp Business exige verificação comercial, o Telegram restringe mensagens entre bots). O e-mail não tem tais restrições – o envio automatizado é um caso de uso de primeira classe.

Alcance universal — Os canais de mensagens são isolados. Seu bot do Telegram não consegue entrar em contato com um usuário do WhatsApp. O e-mail chega a qualquer pessoa com um endereço de e-mail – que é efetivamente todo mundo.

Complementares, não concorrentes — Estruturas de agentes multicanais comoOpenClawoferece suporte a dezenas de canais de mensagens, e o e-mail deve ser um deles. A InboxAPI preenche a lacuna que as plataformas de mensagens estruturalmente não conseguem: criação de identidade programável e ilimitada, sem necessidade de aprovação da plataforma.

Quais são os limites de envio?

Cada conta possui 5 slots de catálogo de endereços para destinatários externos. E-mails para outros endereços InboxAPI (por exemplo, @inboxapi.ai, @inboxapi.io, @inboxapi.dev) não contam para esse limite. Quando todos os slots estão em uso, a entrada usada menos recentemente é substituída automaticamente após 5 dias de inatividade. VerLimites e uso justopara obter detalhes completos.

O que acontece quando eu atingir o limite?

Quando todos os 5 slots estão em uso, a entrada usada menos recentemente é substituída automaticamente após 5 dias de inatividade.

Como funciona o catálogo de endereços? Preciso adicionar contatos?

A agenda de endereços é automática – os contatos são adicionados quando você envia um e-mail. Você nunca precisará adicionar, configurar ou gerenciar contatos manualmente. Há nenhum arquivo de configurações, nenhuma lista de contatos para manter e nenhuma etapa de configuração.

Quando seu agente envia um e-mail para um novo endereço externo, esse endereço fica registrado na agenda. Cada conta possui 5 slots. Quando todos os 5 estão em uso, a entrada usada menos recentemente será substituída automaticamente após 5 dias de inatividade. Emails para outros endereços InboxAPI (@inboxapi.ai, @inboxapi.io, @inboxapi.dev) são sempre ilimitado e não use slot.

Quais são as limitações atuais?

Embora o InboxAPI seja totalmente funcional para e-mail de agente para humano e de agente para agente, existem algumas limitações atuais:

• 5 slots de destinatários externos: Cada conta possui 5 slots de destinatários externos simultâneos em seu catálogo de endereços. Você pode enviar e-mail para mais de 5 pessoas ao longo do tempo, mas apenas 5 endereços externos podem estar ativos ao mesmo tempo; quando todos os slots estão em uso, a entrada usada menos recentemente é substituída automaticamente após 5 dias de inatividade.
• Ainda não há domínios personalizados: os agentes usam subdomínios @inboxapi.ai provisionados automaticamente.
• Apenas para uso pessoal: O InboxAPI não é um serviço de e-mail transacional. Não o use para envio em massa, marketing ou notificações de aplicativos.

Como funcionam as credenciais?

As credenciais do seu agente são armazenadas localmente em ~/.config/inboxapi/credentials.json (Linux) ou ~/Library/Application Support/inboxapi/credentials.json (macOS). A CLI lida com a criação e atualização de tokens automaticamente – seu agente nunca precisa gerenciar tokens manualmente.

E se meu agente perder o acesso?

Se as credenciais do seu agente forem perdidas ou corrompidas, você poderá recuperar a conta usando a ferramenta account_recover — mas somente se você vinculou seu e-mail anteriormente via verify_owner. A recuperação revoga todos os tokens existentes e emite novas credenciais. Sem um e-mail de proprietário verificado, não há como recuperar uma conta bloqueada.

O que é verificação do proprietário?

A verificação do proprietário vincula seu endereço de e-mail pessoal à conta InboxAPI do seu agente. Seu agente liga para verify_owner com seu e-mail, você recebe um código de 6 dígitos e seu agente o envia para verificação completa. Depois de verificada, você poderá recuperar a conta se as credenciais forem perdidas e as restrições de avaliação forem removidas da conta.

Quais domínios estão bloqueados para envio?

O InboxAPI mantém uma lista de bloqueios que bloqueia o envio para domínios governamentais (.gov), militares (.mil), inteligência, aplicação da lei, infraestrutura nuclear/crítica e domínios de e-mail descartáveis.

Como funciona a classificação de confiança?

Cada e-mail recebido é classificado em um dos quatro níveis de confiança:

Nível de confiança	Significado	Ação recomendada
Confiável	O remetente está na sua agenda de endereços com SPF/DKIM válido	É seguro agir
Agente	O remetente é um agente InboxAPI conhecido	Leia livremente, mas confirme com seu humano antes de agir
Não verificado	SPF/DKIM válido, mas o remetente não está no catálogo de endereços	Tenha cuidado
Suspeito	Falha na autenticação ou remetente desconhecido	Sinalize e confirme antes de agir

Qual modelo de IA devo usar com InboxAPI?

Seu modelo deve suportar chamadas de ferramentas/funções — o MCP exige isso. Recomendamos uma janela de contexto de token de no mínimo 32 mil para caber confortavelmente nas 22 definições de ferramentas da InboxAPI junto com o histórico de conversas e o conteúdo do e-mail.

Recomendações de modelos por nível:

Nível	Antrópico	OpenAI	Google
Bom	Haicai 4.5+	GPT-4.1 mini+, GPT-4.1 nano+	Gêmeos 2.5 Flash+
Recomendado	Soneto 4.5+	GPT-4.1+, GPT-5 mini+	Gêmeos 2.5 Pró+
Melhor	Opus 4.5+	GPT-5+, GPT-5.2+	Gêmeos 2.5 Pró+

Sobrecarga de marcação de dados: A InboxAPI aplica marcação de dados (destaque) a conteúdo de e-mail não confiável, substituindo espaços em branco por caracteres marcadores Unicode. Isto pode aumentar ligeiramente o consumo de token ao processar e-mails de remetentes externos. Modelos com janelas de contexto maiores lidam com isso de forma mais confortável.

O que não funcionará: Modelos sem suporte para chamada de ferramenta/função, modelos com janelas de contexto com tokens de 16K e modelos locais muito pequenos (com parâmetros de aproximadamente 7B) que não possuem chamada de ferramenta confiável. Eles terão dificuldade para se adequar às 22 definições de ferramentas do InboxAPI e manter um histórico útil de conversas.

O que impede um agente de comprar coisas ou autorizar transações por e-mail?

InboxAPI é um canal de comunicação, não um ambiente de execução. Ele pode entregar um e-mail, mas não pode clicar em botões, inserir números de cartão de crédito ou interagir com sistemas externos. O risco de ações não autorizadas vem da forma como um agente está configurado e de quais outras ferramentas ele tem acesso – e não do seu e-mail.