NL
Unipile MCP · Unified inbox

Bouw een unified inbox met een coding agent

Gesprekken uit LinkedIn, WhatsApp en e-mail in één lijst, met antwoorden vanuit hetzelfde scherm. Uw agent schrijft het ophalen en samenvoegen met de Unipile MCP-server.
7 dagen gratis proberen, geen creditcard nodig.
Uw agent · support-console
Unipile MCP verbonden
Sarah
Bouw een unified inbox voor LinkedIn, WhatsApp en e-mail.
Request uitvoerenGET /v2/accounts/3 accounts
GET /api/inbox toegevoegd: één call per account, één itemvorm, gesorteerd op datum.
3 bestanden gewijzigd · 3 kanalen in één lijst
Beschrijf de volgende feature…
De opdracht

Wat u wilt bereiken

Toon uw gebruikers alle gesprekken van de accounts die ze hebben gekoppeld in één lijst, en laat ze antwoorden zonder uw product te verlaten. Eerst de eerlijke kant: account_id staat in het pad van elke route, dus een unified inbox is één call per account, gevolgd door een samenvoeging in uw applicatie. Wat de API unificeert is de vorm van de objecten, niet het aantal calls.
Zonder Eén client per provider, elk met een eigen vorm
Een LinkedIn-client, een WhatsApp-client en een e-mailclient, elk met een eigen model en een eigen paginering.
Eén enkele knop "meer laden" die berichten kwijtraakt zodra één account eerder door zijn pagina's heen is dan de andere.
Een antwoord dat via het verkeerde account vertrekt, omdat chat en account niet bij elkaar zijn gehouden.
Met de Unipile MCP-server Het resultaat in uw applicatie
Eén lijst met gesprekken uit LinkedIn, WhatsApp en e-mail, gesorteerd op datum, met het kanaal als badge.
"Meer laden" dat per account één cursor laat oplopen en nooit een bericht kwijtraakt.
Antwoorden vanuit de lijst, via het account dat eigenaar is van de chat, getest op uw Development-applicatie.
Prompt, stappen, code

Geef uw agent de prompt

Twee prompts, elk met de Unipile-endpoints die de agent leest en uitvoert, en wat er in uw project terechtkomt. Paden zijn volledig, op de API-basis-URL https://api.unipile.com, met uw scoped key in de X-API-KEY header.
Uw agent · support-consoleDevelopment-app
Bouw in deze applicatie een unified inbox voor LinkedIn, WhatsApp en e-mail: toon de gekoppelde accounts, haal per account één pagina chats en één pagina e-mails op, normaliseer ze naar één itemvorm en sorteer op datum.
Request uitvoerenGET /v2/accounts/3 accounts
Request uitvoerenGET /v2/{account_id}/chats200 · next_cursor
Toegevoegd GET /api/inbox: toont de accounts, roept GET /v2/{account_id}/chats en GET /v2/{account_id}/emails parallel aan, zet beide om naar één InboxItem (id, account_id, channel, counterpart, preview, date, unread) en sorteert op datum. Een item openen roept de messages-route van die chat aan. Uitgevoerd op de Development-app met een LinkedIn-, een WhatsApp- en een Gmail-testaccount.4 bestanden gewijzigd · getest op de Development-app

Eén call per account, één itemvorm, één sortering

De agent leest via de server de Chat- en Email-schema's en bepaalt de minimale gemeenschappelijke vorm: een identifier, een datum, een afzender, een preview en het kanaal. Alles wat providerspecifiek is, blijft beschikbaar op het ruwe object voor de detailweergave. Instagram en Telegram lopen via dezelfde chatroutes, dus een vierde kanaal is één account extra, geen extra client.
Endpoints die de agent gebruikt
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
Veelgemaakte fout: Zoeken naar een queryfilter op account_id. Het staat in het pad: één call per account, daarna samenvoegen in uw applicatie.
Bouw de LinkedIn-kant in detail
Uw agent · support-consoleDevelopment-app
Voeg paginering toe aan de unified inbox: houd één cursor per gekoppeld account bij, laat elke cursor onafhankelijk oplopen bij "meer laden" en stop een account zodra next_cursor ontbreekt.
Endpoint lezenGET /v2/{account_id}/chatsdata, total_count, next_cursor
Request uitvoerenGET /v2/{account_id}/emails?cursor=…200 OK
De globale offset vervangen door een Map<account_id, next_cursor> die in de inbox-state wordt bijgehouden. "Meer laden" laat elk account dat nog een cursor heeft parallel oplopen en sorteert daarna de samengevoegde lijst opnieuw. Een account zonder next_cursor wordt als uitgeput gemarkeerd en overgeslagen. Gecontroleerd met drie accounts van verschillende grootte op de Development-app.2 bestanden gewijzigd · geen bericht kwijt bij "meer laden"

De envelope is overal hetzelfde: data, total_count, next_cursor

Elke lijstroute geeft dezelfde envelope terug. Geef next_cursor terug in de cursor parameter om de volgende pagina op te halen. Volgens het contract gebruikt u de cursor als de provider die ondersteunt en offset in de andere gevallen, en is limit een plafond, geen garantie: een korte pagina is niet het einde van de lijst, alleen een ontbrekende next_cursor is dat.
Endpoints die de agent gebruikt
GET/v2/{account_id}/chatsGET/v2/{account_id}/emailsGET/v2/{account_id}/chats/{chat_id}/participants
Veelgemaakte fout: Eén cursor voor de hele inbox. Elk account pagineert met een eigen cursor; een gedeelde cursor raakt berichten kwijt zodra één account eerder klaar is dan de andere.
Houd de lijst live met webhooks
Paginering

Eén envelope, één cursor per account

Letterlijk uit het v2-contract dat de agent via de server leest. Dezelfde drie velden komen terug op elke lijstroute.
1De envelopedata bevat de pagina, total_count de omvang als de provider die opgeeft, next_cursor het token voor de volgende pagina. Ontbreekt next_cursor, dan is de lijst van dat account afgelopen.GET https://api.unipile.com/v2/{account_id}/chats?limit=20 { "object": "ChatList", "items": [ … ], "cursor": "…" }
2Cursor of offsetGebruik next_cursor wanneer de provider dat ondersteunt, anders offset. Code die voor elke provider van één van beide uitgaat, breekt op de eerste IMAP-mailbox.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
3De cursormapEén entry per account in de state van uw applicatie. "Meer laden" laat elk account dat nog een cursor heeft oplopen en laat de accounts vallen die er geen teruggaven.{ "acc_1a…": "eyJ…", "acc_9c…": null, "acc_f2…": "eyJ…" } limit is een plafond, geen garantie
Van Development naar productie

Test eerst op een Development-applicatie

Uw Unipile-dashboard scheidt een Development-applicatie van Production. Geef de agent een scoped key uit Development en één testaccount per kanaal: echte paginagroottes, geen echte klant.
1Haal één pagina per account opLinkedIn, WhatsApp en een e-mailaccount, samengevoegd in één lijst gesorteerd op datum.
2Antwoord vanuit de lijstDe verzend-call gaat via het account dat eigenaar is van de chat.
3"Meer laden" met ongelijke accountsGeen bericht kwijt, uitgeputte accounts overgeslagen, zet daarna de key om naar Production.
crm-app · DevelopmentGebruikt door uw agent
Scopedev-tests · 2 accounts
Keyscoped Account API key
AccountsLinkedIn-testaccount, Gmail-testmailbox
Webhooks1 endpoint · berichtevents
crm-app · ProductionOnaangeroerd
Scopeéén per workspace
Keyscoped keys, alleen in uw backend
Accountsde eigen accounts van uw gebruikers, via Hosted Auth
Probleemoplossing

Veelvoorkomende fouten en wat ze betekenen

De vier fouten die een unified inbox breken, en de oplossing voor elk ervan. Drie gaan over paginering.
account_id als queryfilter zoeken
Er wordt verwacht dat één call alle accounts teruggeeft. Oplossingaccount_id staat in het pad. Roep per account één keer aan en voeg samen in uw applicatie; de API unificeert de vorm, niet het aantal calls.
Eén cursor voor de hele inbox
"Meer laden" laat berichten vallen zodra een account eerder klaar is dan de andere. OplossingHoud een map bij van account_id naar next_cursor. Laat elk account onafhankelijk oplopen en stop de accounts die geen cursor teruggaven.
Cursor en offset door elkaar gebruiken
De code werkt bij de ene provider en breekt bij de andere. OplossingGebruik next_cursor wanneer de provider dat ondersteunt en offset in de andere gevallen, zoals het contract voorschrijft. Lees de envelope van elk account in plaats van aannames te doen.
limit als garantie behandelen
Een korte pagina wordt gelezen als het einde van de lijst. Oplossinglimit is een plafond. Alleen een ontbrekende next_cursor beëindigt de lijst van een account; een pagina met minder items dan gevraagd niet.
6000+ Bedrijven innoveren met Unipile
Vertrouwd door marktleiders
1 API
Activiteiten stroomlijnen voor alle belangrijke communicatiekanalen
2 dagen
Snel live integratie bereiken met minimale installatie
30%
Vermindering van onderhoudsinspanningen en -middelen

Ingebouwde beveiliging en compliance

Enterprise-bescherming voor uw gegevens en workflows Meer informatie over onze beveiliging
SOC 2 type II
SOC 2 type II
Gecertificeerd
Onafhankelijk gecontroleerde beveiligingscontroles voor gegevensbescherming en operationele integriteit.
GDPR
GDPR
Conform
Volledige naleving van de Europese regelgeving voor gegevensbescherming voor de privacy van gebruikers.
99.9%
Platform Uptime over de laatste 24 maanden
24/7
Wereldwijde ondersteuning met krachtige API

FAQ unified inbox

Eén call per account, de endpoints die u nodig hebt, paginering over accounts heen, de vorm van berichten en e-mails, en hoe u de lijst live houdt.
Nee, en dat is bewust. account_id maakt deel uit van het pad, dus u roept per account één keer aan en voegt samen in uw applicatie. Wat de API unificeert is de vorm van de objecten, niet het aantal calls.
GET /v2/accounts/ voor de lijst met accounts, daarna GET /v2/{account_id}/chats en GET /v2/{account_id}/emails per account, daarna GET /v2/{account_id}/chats/{chat_id}/messages om een gesprek te openen. Antwoorden gaan via POST /v2/{account_id}/chats/{chat_id}/messages/send en POST /v2/{account_id}/emails/send.
Eén cursor per account. Elke lijstroute retourneert data, total_count en next_cursor. Geef next_cursor terug in de cursor parameter en houd in de state van uw applicatie een map met cursors bij, één per account.
Messaging-gesprekken zijn Chat-objecten en e-mails zijn Email-objecten, elk met eigen velden. De normalisatie gebeurt in uw applicatie op minstens drie velden: identifier, datum en afzender. De agent leest beide schema's via de server en schrijft die mapping.
Met een webhook-endpoint dat geabonneerd is op message.new en email.new. De speciale pagina laat zien hoe een agent dat koppelt.