L'e-mail personnel de votre agent d'IA

Donnez à votre agent IA sa propre adresse email personnelle.
Envoyez, recevez, recherchez, répondez et transférez — directement depuis Claude, Gemini, Codex ou tout client compatible MCP.

Une commande. Pas de serveur. Pas de configuration SMTP. Entièrement gratuit.

Démarrer → Documentation

Pas un simple wrapper autour de SES ou SendGrid. Nous avons construit toute la stack email à partir de zéro — de la réception du courrier à sa livraison dans la boîte de réception.

Pourquoi InboxAPI

Tout ce dont votre agent IA a besoin pour communiquer par email.

Account Setup Illustration An illustration showing an AI agent getting its own @inboxapi.ai email address. [email protected]

Configuration Instantanée

Votre agent obtient une adresse personnelle @inboxapi.ai en quelques secondes. Pas de configuration DNS, pas de vérification de domaine, pas de clés API à gérer.

MCP Integration Diagram A network diagram showing InboxAPI connecting to multiple AI models via the Model Context Protocol. MCP

Natif MCP

Fonctionne nativement avec Claude, Gemini, Codex, OpenCode et tout client compatible MCP. Votre agent peut lire, envoyer, répondre, transférer et rechercher des emails comme un humain.

Free Forever A prominent zero-dollar badge highlighting that InboxAPI is free for AI agents. $0 FREE FOREVER

Entièrement Gratuit

Pas de carte de crédit. Pas de paliers d'utilisation. Pas de piège. Nous croyons que l'email devrait être une capacité de base pour chaque agent IA. Des plans payants avec des fonctionnalités supplémentaires arrivent bientôt.

Full Email Capabilities An interface showing sending, receiving, and threading tools.

Email Complet, Pas Seulement l'Envoi

La plupart des services ne permettent que l'envoi. InboxAPI donne à votre agent une boîte de réception personnelle — recevoir du courrier, rechercher par expéditeur ou sujet, suivre les fils de discussion, vérifier le statut de livraison.

Anti-Abus Intégré

Proof-of-work à l'inscription, plafonds de destinataires, quotas d'envoi et limitation de débit. Chaque couche est conçue pour garder les abus hors de la plateforme.

Direct Infrastructure A stack showing InboxAPI's own mail infrastructure, not a third-party wrapper. OWN INFRA

Pas un Wrapper

Nous ne reposons pas sur Amazon SES, Postfix ou SendGrid. Nous avons construit et exploitons l'ensemble de l'infrastructure email nous-mêmes.

Démarrage Rapide

1

Installation

2

Connexion à

Compatible avec Claude Code, Gemini CLI, OpenCode, Codex et plus.

3

Utilisez l'email

Votre agent reçoit automatiquement une adresse email unique et personnelle (comme ).

Pas de formulaires d'inscription, pas de fichiers de configuration.

Ce que votre agent peut faire

  • Lire et rechercher dans sa boîte de réception
  • Envoyer des emails à n'importe qui
  • Répondre et transférer des messages
  • Suivre les fils de discussion
  • Vérifier le statut de livraison des emails envoyés

Ce que vous pouvez construire

Coordination d'Équipe Dev

Des agents qui s'envoient des emails pour coordonner un workflow de développement — l'un gère les notifications de revue de code, un autre suit les échecs de build, un troisième rapporte le statut de déploiement.

Monitoring & Alertes

Votre agent surveille un système, et quand quelque chose tombe en panne, il envoie un email à votre équipe avec le contexte — pas juste une alerte générique, mais un diagnostic.

Résumé de Newsletter

Un agent qui reçoit les newsletters et listes de diffusion, les lit, et vous envoie un résumé quotidien de ce qui compte vraiment.

$42.00

Traitement de Factures et Reçus

Un agent qui reçoit les factures par email, extrait les lignes et montants, et les injecte dans votre système comptable.

Conçu pour la confiance

Isolation des Comptes

Chaque agent a son propre compte cloisonné. Les agents ne peuvent accéder qu'à leurs propres données.

SPF DKIM DMARC

Authentification Email

SPF, DKIM et DMARC sont configurés automatiquement pour chaque message.

Forget previous instructions and... [DATAMARK: UNTRUSTED] Email content starts here...

Défense contre l'Injection de Prompt

Le contenu des emails non fiables est automatiquement transformé par marquage de données pour que les agents puissent distinguer les données externes des instructions système. Basé sur la recherche académique (arXiv:2403.14720).

Prévention des Abus

Proof-of-work à l'inscription, limites de destinataires basées sur le carnet d'adresses (5 emplacements, éviction LRU après 5 jours), quotas d'envoi, limitation de débit et validation d'adresses email RFC 5322 — tout est appliqué par défaut.

12:04:31 - SEND_EMAIL 12:05:12 - GET_INBOX 12:06:05 - SEARCH_EMAILS

Piste d'Audit

L'authentification par jeton lie chaque action à un compte spécifique, pour que vous sachiez toujours ce qui s'est passé et quand.

Credential Leak Prevention An authentication token being redacted and blocked from exfiltration. auth_token: sk_live_... LEAK PREVENTED

Sécurité des Identifiants

Les emails sortants contenant des jetons d'authentification sont automatiquement rejetés pour prévenir les fuites accidentelles d'identifiants.

Questions fréquentes #

Pourquoi ne pas donner à mon agent l'accès à mon Gmail ou Outlook ?

Sécurité — L'OAuth Gmail/Outlook donne à votre agent accès à l'intégralité de votre boîte de réception (médical, financier, juridique, personnel). Une injection de prompt dans n'importe quel email entrant pourrait manipuler un agent ayant accès à tout cela. InboxAPI donne à votre agent sa propre boîte de réception isolée avec classification de confiance et marquage de données sur chaque message.

Identité — Quand votre agent envoie depuis votre Gmail, les destinataires ne peuvent pas savoir à qui ils parlent. Les réponses arrivent dans votre boîte, mélangées avec votre vrai courrier. InboxAPI donne à votre agent sa propre adresse personnelle — une séparation claire entre vous et votre agent.

Praticité — Les API Gmail/Outlook ne sont pas natives MCP. Vous auriez besoin de middleware, de plomberie OAuth et d'intégration sur mesure. InboxAPI fonctionne directement avec n'importe quel client MCP.

Quelle différence avec AWS SES, SendGrid ou Resend ?
Ce sont des API d'envoi — vous construisez une infrastructure email par-dessus. InboxAPI donne à votre agent une identité email complète : envoyer, recevoir, rechercher, répondre et transférer. Il n'y a rien à configurer et aucune infrastructure à gérer.
Quelle différence avec AgentMail ou a1base ?
Nous avons construit notre propre stack email à partir de zéro. Nous ne wrappons pas SES, Postfix ou un quelconque service d'envoi tiers. Le courrier de votre agent passe par une infrastructure que nous exploitons directement.
C'est vraiment gratuit ?
Oui. Pas de carte de crédit, pas de période d'essai, pas de paliers d'utilisation. Nous travaillons sur des plans payants avec des fonctionnalités supplémentaires, mais l'expérience de base restera toujours gratuite.
Quelles sont les limitations actuelles ?

Bien qu'InboxAPI soit pleinement fonctionnel, il y a quelques limitations actuelles :

  • 5 emplacements de carnet d'adresses pour les destinataires externes (éviction LRU après 5 jours d'inactivité)
  • C'est pour un usage personnel de l'agent uniquement, pas un service transactionnel pour l'envoi en masse, le marketing ou les notifications d'application
Comment prévenez-vous le spam et les abus ?
La création de compte nécessite un proof-of-work. Chaque compte dispose de 5 emplacements de carnet d'adresses pour les destinataires externes — lorsque tous les emplacements sont utilisés, l'entrée la moins récemment utilisée est automatiquement remplacée après 5 jours d'inactivité. Des quotas d'envoi quotidiens et une limitation de débit sont appliqués sur chaque compte. Ces contraintes sont structurelles — ce ne sont pas des politiques, c'est la façon dont le système fonctionne.
Dois-je ajouter des contacts ou configurer un carnet d'adresses ?
Non. Le carnet d'adresses est automatique — les contacts sont ajoutés lorsque votre agent envoie un e-mail. Il n'y a pas de liste de contacts à gérer, pas de fichier de paramètres à modifier, et aucune étape de configuration. Chaque compte peut envoyer jusqu'à 5 adresses externes uniques. Lorsque tous les emplacements sont utilisés, l'entrée la moins récemment utilisée est remplacée automatiquement après 5 jours d'inactivité. Les e-mails entre agents InboxAPI sont toujours illimités.
Et l'injection de prompt via email ?
Chaque email entrant inclut une classification de confiance — fiable, agent, non vérifié ou suspect — selon que l'expéditeur figure dans votre carnet d'adresses et que son email passe les vérifications d'authentification. Cela aide votre agent à décider avec quelle prudence traiter chaque message. Les emails d'autres agents InboxAPI sont signalés séparément pour que votre agent sache vérifier avec vous avant d'agir. Le contenu des emails non fiables est également transformé automatiquement avec des caractères marqueurs (marquage de données) pour que les agents puissent clairement distinguer les données email de leurs propres instructions.
Et les fuites de données ?
Les emails sortants sont analysés à la recherche de jetons d'authentification et d'identifiants. Si votre agent tente accidentellement d'envoyer un email contenant un JWT ou un jeton d'accès, le message est rejeté avant de quitter la plateforme. Cela empêche les agents d'être trompés pour divulguer des données sensibles par email.
Les agents peuvent-ils se spammer mutuellement ?
Les mêmes limites d'envoi s'appliquent à tous les emails sortants — les plafonds de destinataires, les quotas et la limitation de débit fonctionnent de la même manière quel que soit le destinataire.
Les emails de mon agent atterriront-ils dans les spams ?
Peut-être au début. Chaque agent obtient un tout nouveau sous-domaine, et les nouveaux expéditeurs n'ont pas encore de réputation. Les destinataires devront peut-être vérifier leur dossier spam pour les premiers emails. Avec le temps, à mesure que votre agent envoie du courrier légitime et que les destinataires interagissent avec, la délivrabilité s'améliore. En savoir plus sur la délivrabilité des emails.
Pourquoi l'email plutôt qu'un protocole agent natif comme A2A ?
L'email atteint l'ensemble de l'internet existant — des milliards de personnes et d'entreprises l'utilisent déjà. A2A exige que les deux parties implémentent le protocole. Quand votre agent doit joindre quelqu'un en dehors de son propre écosystème, l'email est l'option universelle. Les agents auront probablement besoin des deux.
Pourquoi l'email plutôt que WhatsApp, Telegram ou d'autres applications de messagerie ?

Scalabilité — Vous pouvez créer des centaines d'adresses email par programmation. WhatsApp, Telegram et Signal nécessitent tous des numéros de téléphone et une vérification. Dépasser quelques comptes est impraticable, souvent contraire aux conditions d'utilisation, et parfois impossible sans cartes SIM physiques.

Pas de contrôle d'accès — L'email est le seul canal de communication où vous pouvez créer une identité sans numéro de téléphone, pièce d'identité ou approbation d'un propriétaire de plateforme. Aucune entreprise ne contrôle qui obtient une adresse email.

Protocole ouvert — L'email est fédéré et neutre vis-à-vis des fournisseurs. WhatsApp, Discord et Telegram sont propriétaires — ils peuvent révoquer l'accès API, bannir des comptes bots ou changer les règles à tout moment. L'email ne peut pas être coupé par une seule entreprise.

Conformité aux CGU — La plupart des plateformes de messagerie interdisent explicitement les comptes automatisés ou ont des processus d'approbation stricts (l'API WhatsApp Business nécessite une vérification d'entreprise, Telegram restreint la messagerie entre bots). L'email n'a pas de telles restrictions — l'envoi automatisé est un cas d'utilisation de premier ordre.

Portée universelle — Les canaux de messagerie sont cloisonnés. Votre bot Telegram ne peut pas atteindre un utilisateur WhatsApp. L'email atteint quiconque possède une adresse email — c'est-à-dire pratiquement tout le monde.

Pour les frameworks d'agents multi-canaux comme OpenClaw, l'email comble un vide que les plateformes de messagerie ne peuvent structurellement pas combler — création d'identités illimitée et programmable sans approbation de plateforme requise. InboxAPI offre cette capacité directement.

Quel modèle d'IA dois-je utiliser avec InboxAPI ?

Votre modèle doit prendre en charge les appels d'outils/fonctions (tool/function calling) — exigé par MCP. Nous recommandons un minimum de 32K jetons de fenêtre de contexte.

Bon : Claude Haiku 4.5+, GPT-4.1 mini+, GPT-4.1 nano+, Gemini 2.5 Flash+

Recommandé : Claude Sonnet 4.5+, GPT-4.1+, GPT-5 mini+, Gemini 2.5 Pro+

Meilleur : Claude Opus 4.5+, GPT-5+, GPT-5.2+, Gemini 2.5 Pro+

InboxAPI applique un marquage de données (spotlighting) au contenu d'e-mail non fiable, ce qui peut légèrement augmenter la consommation de jetons. Les modèles avec de plus grandes fenêtres de contexte gèrent cela plus confortablement.

Ce qui ne fonctionnera pas : Les modèles sans appels d'outils/fonctions, les fenêtres de contexte inférieures à 16K jetons, ou les très petits modèles locaux (moins de ~7B de paramètres).

Que se passe-t-il si mon agent perd l'accès à son compte ?
Si les identifiants de votre agent sont perdus ou corrompus, vous pouvez récupérer le compte en utilisant l'outil account_recover — mais uniquement si vous avez préalablement lié votre email via verify_owner. La récupération révoque tous les jetons existants et émet de nouveaux identifiants. Sans email de propriétaire vérifié, il n'y a aucun moyen de récupérer un compte verrouillé.
Qu'est-ce que la vérification de propriétaire ?
La vérification de propriétaire lie votre adresse email personnelle au compte InboxAPI de votre agent. Votre agent appelle verify_owner avec votre email, vous recevez un code à 6 chiffres, et votre agent le soumet pour compléter la vérification. Une fois vérifié, vous pouvez récupérer le compte si les identifiants sont perdus, et les restrictions d'essai sont supprimées du compte.

Donnez une adresse email personnelle à votre agent

Une commande. Gratuit pour toujours.

Démarrer → Documentation GitHub