Unipile MCP · Inbox unifiée

Créer une inbox unifiée avec un agent de codage

Q: Un seul appel API peut-il renvoyer les messages de tous les comptes connectés ?

Non, c'est voulu. account_id fait partie du chemin : vous appelez donc une fois par compte et fusionnez dans votre application. L'API unifie le format des objets, pas le nombre d'appels.

Q: De quels endpoints ai-je besoin pour une inbox unifiée ?

GET /v2/accounts/ pour la liste des comptes, puis GET /v2/{account_id}/chats et GET /v2/{account_id}/emails par compte, puis GET /v2/{account_id}/chats/{chat_id}/messages pour ouvrir une conversation. Les réponses passent par POST /v2/{account_id}/chats/{chat_id}/messages/send et POST /v2/{account_id}/emails/send.

Q: Comment fonctionne la pagination sur plusieurs comptes ?

Un curseur par compte. Chaque route de liste renvoie data, total_count et next_cursor. Renvoyez next_cursor dans le paramètre cursor et gardez une map des curseurs, un par compte, dans l'état de votre application.

Q: Comment garder l'inbox à jour sans polling ?

Avec un endpoint webhook abonné à message.new et email.new. La page dédiée montre comment un agent le branche.

Les conversations LinkedIn, WhatsApp et email dans une seule liste, avec la réponse depuis le même écran. Avec le serveur MCP Unipile, votre agent écrit la récupération et la fusion.

Créer une inbox unifiée avec un agent Docs messagerie

Essai gratuit de 7 jours, sans carte bancaire.

Crée une inbox unifiée LinkedIn, WhatsApp et email.

Exécuter la requêteGET /v2/accounts/3 comptes

Ajout de GET /api/inbox : un appel par compte, un seul format d'élément, tri par date.

3 fichiers modifiés · 3 canaux dans une seule liste

Décrivez la prochaine fonctionnalité…

Le besoin

Ce que vous cherchez à faire

Afficher à vos utilisateurs toutes les conversations des comptes qu'ils ont connectés dans une seule liste, et leur permettre de répondre sans quitter votre produit. D'abord la vérité : account_id figure dans le chemin de chaque route, donc une inbox unifiée, c'est un appel par compte suivi d'une fusion dans votre application. L'API unifie le format des objets, pas le nombre d'appels.

Sans le serveur Un client par fournisseur, un format chacun

Un client LinkedIn, un client WhatsApp et un client email, chacun avec son modèle et sa pagination.

Un seul bouton « charger plus » qui perd des messages dès qu'un compte n'a plus de pages avant les autres.

Une réponse envoyée depuis le mauvais compte, parce que le chat et le compte n'ont pas été gardés ensemble.

Avec le serveur MCP Unipile Le résultat dans votre application

Une seule liste de conversations LinkedIn, WhatsApp et email, triée par date, avec le canal en badge.

Un « charger plus » qui fait avancer un curseur par compte et ne perd jamais un message.

La réponse depuis la liste, sur le compte propriétaire du chat, testée sur votre application Development.

Prompt, étapes, code

Donnez le prompt à votre agent

Deux prompts, chacun avec les endpoints Unipile que l'agent lit et exécute, et ce qui arrive dans votre projet. Les chemins sont complets, sur l'URL de base de l'API https://api.unipile.com, avec votre clé scopée dans l'en-tête X-API-KEY .

Votre agent · support-consoleApplication Development

Crée une inbox unifiée LinkedIn, WhatsApp et email dans cette application : liste les comptes connectés, récupère une page de chats et une page d'emails par compte, normalise-les dans un format d'élément unique et trie par date.

Exécuter la requêteGET /v2/accounts/3 comptes

Exécuter la requêteGET /v2/{account_id}/chats200 · next_cursor

Ajout de GET /api/inbox : liste les comptes, lance en parallèle GET /v2/{account_id}/chats et GET /v2/{account_id}/emails , mappe les deux vers un même InboxItem (id, account_id, channel, counterpart, preview, date, unread) et trie par date. Ouvrir un élément appelle la route messages de ce chat. Exécuté sur l'application Development avec un compte de test LinkedIn, un WhatsApp et un Gmail.4 fichiers modifiés · testé sur l'application Development

Un appel par compte, un format d'élément, un tri

L'agent lit les schémas Chat et Email via le serveur et choisit le format commun minimal : un identifiant, une date, un expéditeur, un aperçu et le canal. Tout ce qui est propre au fournisseur reste disponible dans l'objet brut pour la vue détaillée. Instagram et Telegram passent par les mêmes routes de chat : un quatrième canal, c'est un compte de plus, pas un client de plus.

Endpoints utilisés par l'agent

GET/v2/accounts/GET/v2/{account_id}/chatsGET/v2/{account_id}/emailsGET/v2/{account_id}/chats/{chat_id}/messagesPOST/v2/{account_id}/chats/{chat_id}/messages/sendPOST/v2/{account_id}/emails/send

Erreur fréquente : Chercher un filtre account_id en paramètre de requête. Il est dans le chemin : un appel par compte, puis fusion dans votre application.

Construire le côté LinkedIn en détail

Votre agent · support-consoleApplication Development

Ajoute la pagination à l'inbox unifiée : garde un curseur par compte connecté, fais avancer chacun indépendamment au « charger plus » et arrête un compte quand son next_cursor est absent.

Endpoint de lectureGET /v2/{account_id}/chatsdata, total_count, next_cursor

Exécuter la requêteGET /v2/{account_id}/emails?cursor=…200 OK

Remplacement de l'offset global par une Map<account_id, next_cursor> conservée dans l'état de l'inbox. « Charger plus » fait avancer en parallèle chaque compte qui a encore un curseur, puis retrie la liste fusionnée. Un compte sans next_cursor est marqué comme épuisé et ignoré. Vérifié avec trois comptes de tailles différentes sur l'application Development.2 fichiers modifiés · aucun message perdu au « charger plus »

L'enveloppe est la même partout : data, total_count, next_cursor

Chaque route de liste renvoie la même enveloppe. Renvoyez next_cursor dans le paramètre cursor pour obtenir la page suivante. Le contrat indique d'utiliser le curseur quand le fournisseur le prend en charge et offset sinon, et que limit est un plafond, pas une garantie : une page courte n'est pas la fin de la liste, seule l'absence de next_cursor l'est.

Endpoints utilisés par l'agent

GET/v2/{account_id}/chatsGET/v2/{account_id}/emailsGET/v2/{account_id}/chats/{chat_id}/participants

Erreur fréquente : Un seul curseur pour toute l'inbox. Chaque compte pagine avec son propre curseur ; un curseur partagé perd des messages dès qu'un compte se termine avant les autres.

Garder la liste à jour avec les webhooks

Pagination

Une enveloppe, un curseur par compte

Extrait tel quel du contrat v2 que l'agent lit via le serveur. Les trois mêmes champs reviennent sur chaque route de liste.

1L'enveloppedata contient la page, total_count la taille quand le fournisseur la donne, next_cursor le jeton de la page suivante. Un next_cursor absent signifie la fin de la liste de ce compte.GET https://api.unipile.com/v2/{account_id}/chats?limit=20 { "object": "ChatList", "items": [ … ], "cursor": "…" }

2Curseur ou offsetUtilisez next_cursor dès que le fournisseur le prend en charge, offset sinon. Un code qui suppose l'un des deux pour tous les fournisseurs casse à la première boîte mail IMAP.GET https://api.unipile.com/v2/{account_id}/emails?cursor=…&limit=20 GET https://api.unipile.com/v2/{account_id}/chats?offset=40&limit=20

3La map des curseursUne entrée par compte dans l'état de votre application. « Charger plus » fait avancer chaque compte qui a encore un curseur et écarte ceux qui n'en ont renvoyé aucun.{ "acc_1a…": "eyJ…", "acc_9c…": null, "acc_f2…": "eyJ…" } limit est un plafond, pas une garantie

Du développement à la production

Testez d'abord sur une application Development

Votre dashboard Unipile sépare une application Development de la Production. Donnez à l'agent une clé scopée issue de Development et un compte de test par canal : de vraies tailles de page, aucun vrai client.

1Récupérer une page par compteLinkedIn, WhatsApp et un compte email, fusionnés dans une seule liste triée par date.

2Répondre depuis la listeL'envoi part du compte propriétaire du chat.

3« Charger plus » avec des comptes inégauxAucun message perdu, comptes épuisés ignorés, puis passage de la clé en Production.

crm-app · DevelopmentUtilisé par votre agent

Scopedev-tests · 2 comptes

Cléclé Account API scopée

ComptesCompte de test LinkedIn, boîte mail de test Gmail

Webhooks1 endpoint · événements de message

crm-app · ProductionIntacte

Scopeune par workspace

Cléclés scopées, uniquement dans votre backend

Comptesles comptes de vos utilisateurs, via Hosted Auth

Dépannage

Erreurs fréquentes et leur signification

Les quatre erreurs qui cassent une inbox unifiée, et la correction de chacune. Trois concernent la pagination.

Chercher account_id comme filtre de requête

On attend d'un seul appel qu'il renvoie tous les comptes. Correctionaccount_id est dans le chemin. Appelez une fois par compte et fusionnez dans votre application ; l'API unifie le format, pas le nombre d'appels.

Un seul curseur pour toute l'inbox

« Charger plus » perd des messages dès qu'un compte se termine avant les autres. CorrectionGardez une map de account_id vers next_cursor. Faites avancer chaque compte indépendamment et arrêtez ceux qui n'ont renvoyé aucun curseur.

Mélanger curseur et offset

Le code fonctionne avec un fournisseur et casse avec un autre. CorrectionUtilisez next_cursor quand le fournisseur le prend en charge et offset sinon, comme l'indique le contrat. Lisez l'enveloppe de chaque compte au lieu de faire des suppositions.

Considérer limit comme une garantie

Une page courte est interprétée comme la fin de la liste. Correctionlimit est un plafond. Seule l'absence de next_cursor termine la liste d'un compte ; une page avec moins d'éléments que demandé, non.

6000+ Les entreprises qui innovent avec Unipile

Des entreprises leaders nous font confiance

1 API

Toutes les plateformes centralisées en une API

2 jours

Intégration très rapide

30%

Réduction des efforts et des ressources de maintenance

Sécurité et conformité

Une protection de niveau entreprise pour vos données et workflows En savoir plus sur notre sécurité

SOC 2 Type II

Certifié

Contrôles de sécurité vérifiés de manière indépendante garantissant la protection des données et l'intégrité opérationnelle.

GDPR

Conforme à la loi

Conformité totale avec les réglementations européennes en matière de protection des données pour le respect de la vie privée des utilisateurs.

99.9%

Temps de disponibilité de la plateforme au cours des 24 derniers mois

24/7

Support mondial avec API performante

FAQ inbox unifiée

Un appel par compte, les endpoints nécessaires, la pagination sur plusieurs comptes, le format des messages et des emails, et comment garder la liste à jour.

Non, c'est voulu. account_id fait partie du chemin : vous appelez donc une fois par compte et fusionnez dans votre application. L'API unifie le format des objets, pas le nombre d'appels.

GET /v2/accounts/ pour la liste des comptes, puis GET /v2/{account_id}/chats et GET /v2/{account_id}/emails par compte, puis GET /v2/{account_id}/chats/{chat_id}/messages pour ouvrir une conversation. Les réponses passent par POST /v2/{account_id}/chats/{chat_id}/messages/send et POST /v2/{account_id}/emails/send.

Un curseur par compte. Chaque route de liste renvoie data, total_count et next_cursor. Renvoyez next_cursor dans le paramètre cursor et gardez une map des curseurs, un par compte, dans l'état de votre application.

Les conversations de messagerie sont des objets Chat et les emails des objets Email, chacun avec ses propres champs. La normalisation se fait dans votre application sur au moins trois champs : identifiant, date et expéditeur. L'agent lit les deux schémas via le serveur et écrit ce mapping.

Avec un endpoint webhook abonné à message.new et email.new. La page dédiée montre comment un agent le branche.