Jak odczytywać wiadomości e-mail przez API: przewodnik dewelopera po dostępie do skrzynki odbiorczej (2026)

Przewodnik dla programistów 2026

Jak czytać e-maile przez API: Przewodnik dla deweloperów Dostęp do skrzynki odbiorczej

Zakres Ten poradnik obejmuje synchronizuj API do odczytu istniejących skrzynek odbiorczych użytkowników — Gmail API, Microsoft Graph, IMAP oraz zunifikowane warstwy, takie jak Unipile. Różni się to od usług transakcyjnych (SendGrid, Mailgun), które wysyłają pocztę wychodzącą z domen Twojej firmy.

Twórz produkty, które programowo odczytują wiadomości e-mail użytkowników. Z jednego POBIERZ /api/v1/emails W niniejszym przewodniku omówiono wszystkie metody wywoływania webhooków w czasie rzeczywistym wraz z działającym kodem w językach Node.js, Python i cURL.

odczytaj_skrzynkę_odbiorczą.js
// Odczytaj e-maile za pomocą jednego ujednoliconego wywołania API const response = czekać fetch( 'https://api3.unipile.com:PORT/api/v1/emails', { nagłówki: { 'Klucz API X': process.env.UNIPILE_API_KEY, 'id_konta': accountId } } ); const { e-maile } = czekać odzew.json(); // Ten sam kształt JSON dla Gmail, Outlook i IMAP e-maile.dla każdego(email => { konsola.log(email.temat, email.od_uczestnika); });
200 OK - zwrócono 47 emaili (Gmail + Outlook + IMAP)
Współpracuje z: Gmail Perspektywy IMAP Gmail, Outlook i IMAP
Definicja

Co to jest interfejs API do odczytu wiadomości e-mail?

API do odczytu poczty e-mail to interfejs HTTP, który pozwala Twojej aplikacji na dostęp do wiadomości e-mail z istniejącej skrzynki pocztowej użytkownika, ich pobieranie i przetwarzanie – bez przechowywania haseł czy tworzenia specyficznych dla dostawcy integracji. Jest to fundament każdego produktu wymagającego wglądu do skrzynki odbiorczej: synchronizacji CRM, asystentów e-mail opartych na sztucznej inteligencji, automatyzacji wsparcia czy archiwizacji zgodności.

Szybka definicja

A odczytaj API poczty e-mail udostępnia punkty końcowe do uwierzytelniania za pomocą skrzynki pocztowej użytkownika (za pomocą poświadczeń OAuth 2.0 lub IMAP), listowania wiadomości w skrzynce odbiorczej, pobierania pełnych treści wiadomości e-mail z załącznikami oraz subskrybowania zdarzeń dostarczania w czasie rzeczywistym. Działa on na istniejącym koncie Gmail, Outlook lub IMAP użytkownika - nie domenę, nad którą masz kontrolę. Odróżnia to od transakcyjnych API poczty e-mail (SendGrid, Mailgun, Resend), które wysyłają pocztę wychodzącą w imieniu Twojej aplikacji.

Ten poradnik obejmuje
API synchronizacji / odczytu poczty e-mail

Połącz się z istniejącymi skrzynkami pocztowymi użytkowników. Odczytuj, synchronizuj i reaguj na wiadomości e-mail w czasie rzeczywistym. Uwierzytelnianie za pomocą OAuth 2.0 lub IMAP. Użytkownik udziela dostępu do swojej własnej skrzynki pocztowej.

Przykłady: Gmail API, Microsoft Graph, IMAP, Unipile
Nie ten przewodnik
API do e-maili transakcyjnych

Wysyłaj e-maile wychodzące z domen, które kontrolujesz. Używane do potwierdzeń, powiadomień, resetowania haseł. Brak dostępu do skrzynki odbiorczej.

Przykłady: SendGrid, Mailgun, Resend, Postmark
Przypadki użycia

Dlaczego programistyczne czytanie e-maili ma znaczenie

Możliwość odczytu wiadomości e-mail użytkowników za pośrednictwem API otwiera kategorię produktów, które były po prostu niemożliwe przy użyciu samego SMTP. Oto cztery główne przypadki użycia napędzające wdrożenia w 2026 roku.

Synchronizacja CRM i Sales Engagement

Narzędzia sprzedażowe potrzebują dostępu do każdej wymiany mailowej między przedstawicielem handlowym a potencjalnym klientem – automatycznie, bez ręcznego logowania. API do odczytu poczty elektronicznej pobiera rozmowy bezpośrednio z skrzynki odbiorczej przedstawiciela i synchronizuje je w czasie rzeczywistym z Twoim systemem CRM.

Automatyczne logowanie wymiany e-maili do rekordów kontaktów
Sygnały dotyczące transakcji powierzchniowe z wątków skrzynki odbiorczej
Wykryj zamiar odpowiedzi i zaktualizuj etap potoku

Agenty AI i Asystenci E-mail

Duże modele językowe potrzebują kontekstu. Dostarczając agentowi AI strumień e-maili przychodzących w czasie rzeczywistym, można tworzyć kopilotów, którzy automatycznie tworzą odpowiedzi, podsumowują wątki, wyodrębniają zadania do wykonania i ustalają priorytety rozmów.

Przesyłaj nowe wiadomości e-mail do potoku przetwarzania LLM
Wygeneruj kontekstowe wersje robocze odpowiedzi
Wyodrębnij zadania, daty i zobowiązania z wątków

Automatyzacja obsługi klienta

Zespoły wsparcia otrzymują tysiące e-maili dziennie. API do odczytu e-maili pozwala Twojej platformie klasyfikować przychodzące zgłoszenia, kierować je do odpowiedniej kolejki i uruchamiać zautomatyzowane odpowiedzi – wszystko to, zanim człowiek otworzy zgłoszenie.

Klasyfikuj wiadomości e-mail z działu pomocy według tematu i pilności
Routing do kolejek agentów na podstawie treści e-mail
Wyzwól automatyczne odpowiedzi dla typowych wzorców zapytań

Zgodność, Archiwizacja i eDiscovery

Regulowane branże muszą przechowywać i indeksować każdego e-maila. API do odczytu poczty e-mail zapewnia programistyczny dostęp niezbędny do ciągłego archiwizowania skrzynek odbiorczych, oznaczania naruszeń zasad i dostarczania zapisów e-mail na żądanie do celów przeglądu prawnego.

Ciągłe archiwizowanie skrzynki odbiorczej pod kątem zgodności z RODO / FINRA
Wykrywanie naruszeń polityki w skrzynkach pocztowych pracowników
Eksport eDiscovery na żądanie z blokadą prawną
Dogłębna analiza dostawcy

Natywne interfejsy API do odczytu wiadomości e-mail: Gmail, Outlook i IMAP

Każdy główny dostawca poczty e-mail udostępnia własne API odczytu z różnymi punktami końcowymi, modelami uwierzytelniania i możliwościami. Oto jak wyglądają one w praktyce.

Gmail API

OAuth 2.0

API Gmail jest interfejsem API REST zbudowanym na infrastrukturze Google. Używa lista wiadomości użytkowników aby stronicować skrzynkę pocztową i użytkownicy.wiadomości.pobierz do pobierania pełnej wiadomości. Obsługuje powiadomienia push przez Google Pub/Sub, umożliwiając monitorowanie skrzynki odbiorczej w czasie rzeczywistym bez odpytywania. Limit użycia: 250 jednostek limitu na użytkownika na sekundę.

gmail_read.sh
# Wyświetl wiadomości w skrzynce odbiorczej (API Gmaila) zwijać się -X POBIERZ \ "https://gmail.googleapis.com/gmail/v1/users/me/messages?labelIds=INBOX&maxResults=20" \ -H "Autoryzacja: Bearer ACCESS_TOKEN" # Pobierz pojedynczy e-mail wraz z pełną treścią zwijać się -X POBIERZ \ "Tutaj nie ma tekstu do przetłumaczenia. Jest to adres URL." \ -H "Autoryzacja: Bearer ACCESS_TOKEN"
Uwaga: Gmail zwraca wiadomości jako części MIME zakodowane w Base64. Musisz samodzielnie zdekodować każdą część i przeanalizować granice wieloczęściowe, aby wyodrębnić zwykły tekst, treść HTML i załączniki.

Microsoft Graph (Outlook i Microsoft 365)

OAuth 2.0

Microsoft Graph to ujednolicone API dla wszystkich usług Microsoft 365, w tym osobistych kont Outlook, Exchange Online i skrzynek pocztowych firmowych Microsoft 365. /ja/wiadomości endpoint zwraca wiadomości z pełną treścią w jednym żądaniu. Stronicowanie używa $pomiń oraz $góra Parametry OData. Zobacz pełny Przewodnik po integracji poczty e-mail w Microsoft Graph szczegóły.

graph_read.sh
# Wyświetlanie wiadomości w skrzynce odbiorczej (Microsoft Graph) zwijać się -X POBIERZ \ "https://graph.microsoft.com/v1.0/me/messages?\$top=20&\$filter=parentFolderId eq 'inbox'' \ -H "Autoryzacja: Bearer ACCESS_TOKEN" \ -H "Typ-Zawartości: application/json" # Pobierz pojedynczą wiadomość wraz z treścią zwijać się -X POBIERZ \ "https://graph.microsoft.com/v1.0/me/messages/MESSAGE_ID?\$select=subject,body,from,receivedDateTime" \ -H "Autoryzacja: Bearer ACCESS_TOKEN"
Uwaga: Microsoft Graph ogranicza przepustowość do 10 000 żądań na 10 minut na aplikację na dzierżawcę. Treść wiadomości jest zwracana jako HTML lub tekst w zależności od $wybierz oraz Akceptuj nagłówki.

IMAP

Protokół uniwersalny

IMAP (Internet Message Access Protocol) to uniwersalny protokół poczty e-mail obsługiwany przez praktycznie każdy serwer pocztowy. Nie jest to REST API, ale stanowe połączenie TCP przez port 993 (TLS). Wydajesz polecenia typu POBIERZ, SZUKAJoraz BEZCZYNNOŚĆ przez połączenie. Aby dowiedzieć się więcej, zobacz nasze Przewodnik po integracji API IMAP.

imap_read.py
import imaplib, e-mail # – Połącz się i uwierzytelnij poczta = imaplib.IMAP4_SSL('imap.przykład.com') poczta.zaloguj('user@example.com', 'app_password') poczta.wybierz('SKRZYNKA') # Szukaj ukrytych wiadomości status, identyfikatory_wiadomości = poczta.wyszukiwanie(Żaden, 'NIEWIDZIANY') dla identyfikator_wiadomości w message_ids[0].podzielić(): _, dane = poczta.fetch(id_wiadomości, '(RFC822)') wiadomość = e-mail.wiadomość_z_bajtów(dane[0][1]) print(komunikat['temat'], komunikat['z'])
Uwaga: IMAP wymaga utrzymania długo działających połączeń TCP i samodzielnego zarządzania pulami połączeń. Dostarczanie w czasie rzeczywistym wykorzystuje BEZCZYNNOŚĆ komenda, która utrzymuje połączenie otwarte i czeka na powiadomienia od serwera. Nie skaluje się łatwo powyżej kilkuset jednoczesnych kont.
A co z Yahoo i innymi dostawcami?

Yahoo Mail, ProtonMail, Zoho i inni dostawcy obsługują IMAP jako uniwersalne rozwiązanie zapasowe, więc są objęci powyższym podejściem IMAP. Niektórzy (jak Yahoo) udostępniają również ograniczone, własne interfejsy API, ale żaden nie dorównuje możliwościom interfejsu API Gmaila ani Microsoft Graph. W przypadku większości produktów obejmujących wielu dostawców, IMAP jest uniwersalnym rozwiązaniem zapasowym dla każdej skrzynki pocztowej, która nie jest obsługiwana przez Gmaila ani Outlook OAuth. A ujednolicone API pocztowe automatycznie przeprowadza tę negocjację.

Inżynieria Rzeczywistości

Ukryta złożoność czytania e-maili na dużą skalę

Stworzenie integracji API do odczytu poczty e-mail dla jednego dostawcy na potrzeby demonstracji zajmuje popołudnie. Stworzenie takiej, która będzie niezawodnie działać u wszystkich dostawców w skali produkcyjnej, to zupełnie inne wyzwanie. Oto, co faktycznie obejmuje inżynieria.

01

Przepływ OAuth na dostawcę

Każdy dostawca ma własną implementację OAuth 2.0, wymagania dotyczące ekranu zgody, zakresy i cykl życia tokenu. Obsługa Gmaila i Outlooka oznacza utrzymanie dwóch oddzielnych aplikacji OAuth, dwóch konsol deweloperskich, dwóch strategii odświeżania tokenów i dwóch zestawów wymogów zgodności (Google CASA Tier 2, Microsoft Publisher Verification).

GmailAplikacja Google Cloud Console, CASA Tier 2 dla wrażliwych zakresów, godzinne tokeny dostępu
Outlook:Rejestracja aplikacji w Azure AD, weryfikacja wydawcy, konfigurowalny czas życia tokenu
IMAPHasła do aplikacji lub OAuth (IMAP Gmail używa tego samego przepływu Google OAuth)
02

Różnice w paginacji

Każdy dostawca stosuje inne metody paginacji. Gmail używa nieprzezroczystych tokenów stron. Microsoft Graph używa OData. $pomiń oraz następny link Kursor. IMAP używa numerycznych zakresów UID. Wdrożenie spójnej abstrakcji stronicowania we wszystkich trzech wymaga nietrywialnego kodu adaptera.

Gmailtoken strony, maksymalnie 500 wyników na stronę
Wykres:@odata.nextLink – adres URL, parametry $top/$skip
IMAPZakresy pobierania UID, CONDSTORE do synchronizacji przyrostowej
03

Parsowanie MIME

E-maile przychodzą jako surowe dokumenty MIME z zagnieżdżonymi granicami wieloczęściowymi, kodowaniem base64 lub quoted-printable, wieloma zestawami znaków i załącznikami w tekście. Gmail zwraca części zakodowane w base64url. IMAP zwraca surowe RFC 822. Żaden z nich nie dostarczy czystego, zwykłego tekstu bez parsowania całego drzewa MIME.

Ryzyko:Znaki międzynarodowe, emotikony i tekst od prawej do lewej wprowadzają skrajne przypadki kodowania, które uszkadzają treść główną
Załączniki:Należy przejść przez drzewo MIME, aby znaleźć części typu Content-Disposition: attachment
04

Limity żądań i wycofywanie

Gmail wymusza 250 jednostek limitu na użytkownika na sekundę (wystawienie kosztuje 5 jednostek, pobranie 5 jednostek). Microsoft Graph stosuje ograniczenia 10 000 żądań na 10 minut na aplikację na dzierżawcę. Oba zwracają błędy 429, które wymagają wykładniczego wycofywania z dodaniem losowości. Przy 1000 połączonych kontach zarządzanie limitami żądań staje się pełnoprawnym problemem inżynieryjnym.

Gmail250 jednostek limitu/sec/użytkownik. Dzienny limit: 1 miliard jednostek
Wykres:10 000 żądań / 10 min / aplikacja / dzierżawa. Nagłówek Retry-After
IMAPSpecyficzne dla dostawcy, zazwyczaj 10-20 jednoczesnych połączeń na konto
05

Na żywo: Webhooki vs Polling vs IDLE

Otrzymywanie powiadomień o nowych wiadomościach e-mail wymaga zupełnie innych mechanizmów w zależności od dostawcy. Gmail używa subskrypcji push Google Pub/Sub, które muszą być odnawiane co 7 dni. Microsoft Graph używa subskrypcji powiadomień o zmianach z maksymalnym okresem ważności 4230 minut. IMAP używa polecenia IDLE, które utrzymuje stałe połączenie TCP na konto.

GmailWiadomości wypychane do Pub/Sub, 7-dniowy okres ważności, wymaga cyklu odnawiania
Wykres:subskrypcja powiadomień, maksymalny czas ważności ~3 dni
IMAPPolecenie IDLE, 1 stałe połączenie TCP na konto
06

Niespójności wątków u różnych dostawców

Gmail domyślnie grupuje wiadomości w wątki. Microsoft Graph posiada pole conversationId, ale wątki działają inaczej niż w Gmailu. IMAP nie posiada natywnego wątkowania – należy ręcznie rekonstruować wątki, dopasowując nagłówki References i In-Reply-To. Budowanie ujednoliconego widoku wątków obejmującego różne dostawców wymaga znacznej logiki normalizacyjnej.

GmailNative threadId, messages.list?labelIds=INBOX zwraca grupy wątków
Wykres:conversationId, ale nie jest to odpowiednik wątków w Gmailu
IMAPMuszę ręcznie parsować nagłówki Message-ID / References
Architektura

Architektura API do odczytu wiadomości e-mail: porównanie 3 podejść

Nie ma jednej "poprawnej" architektury do odczytu wiadomości e-mail. Właściwe podejście zależy od tego, ilu dostawców musisz obsługiwać, od posiadanych zasobów inżynierskich i wymagań skalowalności. Oto szczere porównanie.

Podejście Zalety Kons Kiedy używać
API bezpośrednich dostawców
Gmail API, Microsoft Graph
Poziom bezpłatny, pełny dostęp do funkcji, brak opóźnień pośrednich Konfiguracja OAuth na dostawcę, parsowanie MIME, oddzielne zarządzanie limitami żądań, brak normalizacji między dostawcami Tylko jeden dostawca
Samodzielny IMAP
imaplib, node-imap
Uniwersalny protokół, działa z każdą skrzynką pocztową, nie wymaga aplikacji OAuth Połączenia TCP ze stanem, brak powiadomień push (polling lub IDLE), zarządzanie pulą połączeń, wolne w skali Tylko starsze wersje / lokalnie
Zunifikowane API do odczytu poczty e-mail
Unipile
Jednolity endpoint dla wszystkich dostawców, znormalizowana odpowiedź JSON, zarządzany OAuth, ujednolicone webhooki, wbudowana logika ponawiania prób Dodatkowy koszt wywołania API na połączone konto, zewnętrzne zależności Produkty wielodostawcowe
API bezpośrednich dostawców
Gmail API, Microsoft Graph
Zalety Poziom bezpłatny, pełny dostęp do funkcji, brak opóźnień pośrednich
Kons Konfiguracja OAuth na dostawcę, parsowanie MIME, oddzielne zarządzanie limitami żądań, brak normalizacji między dostawcami
Kiedy używać Tylko jeden dostawca
Samodzielny IMAP
imaplib, node-imap
Zalety Uniwersalny protokół, działa z każdą skrzynką pocztową, nie wymaga aplikacji OAuth
Kons Połączenia TCP ze stanem, brak powiadomień push (polling lub IDLE), zarządzanie pulą połączeń, wolne w skali
Kiedy używać Tylko starsze wersje / lokalnie
Zunifikowane API do odczytu poczty e-mail
Unipile
Zalety Jednolity endpoint dla wszystkich dostawców, znormalizowana odpowiedź JSON, zarządzany OAuth, ujednolicone webhooki, wbudowana logika ponawiania prób
Kons Dodatkowy koszt wywołania API na połączone konto, zewnętrzne zależności
Kiedy używać Produkty wielodostawcowe
Najlepsze dla jednego dostawcy
API Dostawcy Bezpośredniego

Jeśli każdy użytkownik Twojego produktu korzysta z Gmaila, zbuduj integrację bezpośrednio z interfejsem API Gmaila. Uzyskasz pełną funkcjonalność, brak dodatkowych kosztów oraz dostęp do specyficznych funkcji Gmaila, takich jak etykiety, wątki i powiadomienia z Pub/Sub.

Najlepsze dla systemów dziedziczonych
Samodzielny IMAP

Serwery poczty lokalnej, rozwiązania firmowe Exchange bez dostępu do interfejsu Graph API, lub dowolny scenariusz, w którym OAuth nie jest dostępny. Używaj IMAP jako metody awaryjnej, a nie podstawowej strategii dla nowych produktów.

Najlepsze dla produktów SaaS
Ujednolicone API do odczytu poczty e-mail

Kiedy użytkownicy mają skrzynki pocztowe Gmail, Outlook i IMAP, a potrzebujesz jednolitego interfejsu API do odczytu poczty e-mail, zunifikowana warstwa, taka jak Unipile, całkowicie eliminuje problem integracji z wieloma dostawcami.

5-minutowa konfiguracja

Czytanie e-maili za pomocą zunifikowanego API do odczytu e-maili Unipile

Unipile abstrakcjonizuje Gmail API, Microsoft Graph i IMAP za pomocą jednego API do odczytu poczty e-mail. Jeden przepływ OAuth, jeden punkt końcowy, jedna znormalizowana forma JSON - niezależnie od tego, u którego dostawcy znajduje się skrzynka pocztowa użytkownika. Oto jak odczytać pierwszą skrzynkę pocztową w mniej niż 5 minut.

1
Uwierzytelnij użytkownika za pomocą hostowanego linku uwierzytelniającego

Wygeneruj hostowany adres URL uwierzytelniania z pulpitu nawigacyjnego Unipile. Wyślij ten link do swojego użytkownika – on wykona przepływ zgody OAuth dla swojego dostawcy (dane logowania do Gmail, Outlook lub IMAP) na stronie hostowanej przez Unipile. Żadnej konfiguracji aplikacji OAuth, żadnego konfigurowania identyfikatora URI przekierowania po Twojej stronie. Zobacz Przewodnik po zunifikowanym API e-mail dla pełnego przepływu uwierzytelniania.

auth_link.sh
# Wygeneruj link do uwierzytelniania hostowanego dla swojego użytkownika zwijać się -X POST \ "https://api3.unipile.com:PORT/api/v1/hosted/accounts/link" \ -H "X-API-KEY: TWÓJ_KLUCZ_API" \ -H "Typ-Zawartości: application/json" \ -d '{"type":"EMAIL","name":"user@example.com","success_redirect_url":"https://yourapp.com/connected"}' Odpowiedź #: { "url": "https://auth.unipile.com/..." } # Wyślij ten adres URL do użytkownika – użytkownik przeprowadzi proces OAuth u swojego dostawcy
2
Wyświetl wiadomości w skrzynce odbiorczej - GET /api/v1/emails

Gdy użytkownik połączy swoje konto, wywołaj punkt końcowy poczty e-mail z jego account_id. Odpowiedź jest identyczna niezależnie od tego, czy podstawowa skrzynka pocztowa to Gmail, Outlook czy IMAP.

list_emails.sh
# Wyświetl listę wiadomości e-mail w skrzynce odbiorczej (działa w Gmailu, Outlooku i IMAP) zwijać się -X POBIERZ \ "https://api3.unipile.com:PORT/api/v1/emails?account_id=ACCOUNT_ID&limit=50" \ -H "X-API-KEY: TWÓJ_KLUCZ_API" # Filtruj według folderu zwijać się "...?account_id=ACCOUNT_ID&folder=SKRZYNKA&limit=50" -H "X-API-KEY: TWÓJ_KLUCZ_API" # – filtruj tylko nieprzeczytane zwijać się "...?account_id=ACCOUNT_ID&unread=true" -H "X-API-KEY: TWÓJ_KLUCZ_API"
200 OK - znormalizowane JSON, taki sam kształt dla wszystkich dostawców
3
Pobierz pojedynczy e-mail z treścią i załącznikami

Pobierz pełny e-mail według identyfikatora. Unipile zwraca zdekodowany, znormalizowany obiekt z treścią w postaci zwykłego tekstu, treścią HTML i metadanymi załączników - nie jest wymagane żadne parsowanie MIME po Twojej stronie.

get_email.sh
# Pobierz pojedynczy e-mail wraz z pełną treścią i załącznikami zwijać się -X POBIERZ \ "https://api3.unipile.com:PORT/api/v1/emails/EMAIL_ID" \ -H "X-API-KEY: TWÓJ_KLUCZ_API" Pola odpowiedzi # (zawsze znormalizowane): # { "id", "temat", "data", "od_uczestnika", "do_uczestników", # "body", "body_plain", "attachments": [{ "id", "filename", "size" }] }
4
Odbieraj nowe wiadomości e-mail w czasie rzeczywistym za pomocą webhooków

Zarejestruj punkt końcowy webhooka na swoim pulpicie nawigacyjnym Unipile. Unipile abstrahuje Gmail Pub/Sub, powiadomienia o zmianach Microsoft Graph i IMAP IDLE w jedno email.received zdarzenie. Brak odnowienia subskrypcji, brak puli połączeń IDLE do zarządzania.

webhook_handler.js
// Unipile wywołuje Twój punkt końcowy, gdy przychodzi nowy e-mail // To samo zdarzenie dla użytkowników Gmail, Outlook i IMAP aplikacja.stanowisko('/webhooks/email', (req, res) => { const { zdarzenie, identyfikator_konta, identyfikator_e_mail } = req.body; jeśli (zdarzenie === 'email.received') { // Pobierz pełne szczegóły wiadomości e-mail przetwarzajNowyEmail(id_konta, id_email); } rez.status(200); });
Jedno zdarzenie webhook zastępuje Gmail Pub/Sub + subskrypcje Graph + IMAP IDLE
Czy chcesz pełne odniesienie do integracji?

Pełny przewodnik po API poczty e-mail szczegółowo omawia uwierzytelnianie, wszystkie punkty końcowe, stronicowanie, pobieranie załączników, bezpieczeństwo i zgodność.

Przeczytaj Przewodnik po interfejsie API wiadomości e-mail
Przykłady kodu

Czytanie e-maili: Przykłady kodu według języka

Gotowe do produkcji fragmenty kodu do odczytu wiadomości e-mail za pomocą ujednoliconego interfejsu API do odczytu wiadomości e-mail Unipile. Wszystkie przykłady odczytują z kont Gmail, Outlook i IMAP przy użyciu tego samego kodu.

Node.js / TypeScript
Python
Idź
readEmails.ts
import fetch z 'węzeł-pobieranie'; const BAZA = 'https://api3.unipile.com:PORT/api/v1'; const Klucz API = process.env.UNIPILE_API_KEY!; interfejs E-mail { id: łańcuch; temat: łańcuch; data: łańcuch; od_uczestnika: { wyświetlana_nazwa: łańcuch; identyfikator: łańcuch }; body: łańcuch; Treść: łańcuch; załączniki: { id: łańcuch; nazwa pliku: łańcuch; rozmiar: liczba }[]; } // Lista e-maili w skrzynce odbiorczej - działa dla Gmaila, Outlooka i IMAP async function listaEmaili(numerKonta: łańcuch, limit = 50) { const res = czekać fetch( `${BASE}/emails?account_id=${accountId}&limit;=${limit}&folder;=INBOX`, { nagłówki: { 'Klucz API X': KLUCZ_API } } ); const dane = czekać rez.json(); return elementy danych jako E-mail[]; } // Pobierz pojedynczego e-maila z pełnym tekstem + załącznikami async function PobierzEmail(idEメール: łańcuch) { const res = czekać fetch(`${BASE}/emails/${emailId}`, { nagłówki: { 'Klucz API X': KLUCZ_API } } ); return czekać rez.json() jako E-mail; } // Użycie const e-maile = czekać listaEmaili('acc_01abc...'); e-maile.dla każdego(e => konsola.log(e.temat, e.od_uczestnika.identyfikator));
read_emails.py
import osi import żądania BAZA = "https://api3.unipile.com:PORT/api/v1" NAGŁÓWKI = {"X-API-KEY": os.environ["UNIPILE_API_KEY"]} def list_emails(identyfikator_konta: str, limit: int = 50) -> lista: "Wyświetl e-maile w skrzynce odbiorczej — działa dla Gmaila, Outlooka i IMAP." odpowiadaj = żądania.uzyskać( f"{BAZA}/maile", headers=HEADERS, parametry={ "account_id": identyfikator_konta, "limit"limit, "folder": "SKRZYNKA ODBIORCZA", }, ) lub.podnieś_status() return lub.json()["przedmioty"] def pobierz_email(email_id: str) -> dict: "Pobierz pojedynczy e-mail wraz z treścią i załącznikami." odpowiadaj = żądania.uzyskać(f"{BAZA}/emails/{email_id}", nagłówki=NAGŁÓWKI) lub.podnieś_status() return lub.json() # Użycie e-maile = list_emails("acc_01abc...") dla e-mail w e-maile: print(email"temat"], e-mail["od_uczestnika"]["identyfikator"]) # Pobierz treść pełną pierwszego e-maila pełny = pobierz_emailE-maile0]["id"]) print(pełny"ciało_zwykłe"])
read_emails.go
opakowanie główny import ( "kodowanie/json" "fmt" "net/http" "os" ) typ E-mail struktura { ID łańcuch `json:"id"` Temat łańcuch `json:"temat"` Ciało łańcuch `json:"body_plain"` } typ ListaOdpowiedzi struktura { Przedmioty []E-mail `json:"przedmioty"` } funkcja listaEmaili(accountID string) ([]E-mail, błąd) { url := "https://api3.unipile.com:PORT/api/v1/emails?account_id=" + ID_konta żądanie, _ := http.NoweŻądanie("POBIERZ", adres url, nie) Nagłówek req.Zestaw("X-API-KEY", os.Getenv("UNIPILE_API_KEY")) resp, err := http.DefaultClient.Dowymagaj jeśli błąd != nie { return nie, błąd } przełożyć resp.Body.Zamknij() zmienna wynik ListaOdpowiedzi json.Dekoder(resp.Ciało).Dekoduj(&wynik) return result.Elementy, nie } funkcja główny() { e-maile, _ := listaEmaili("acc_01abc...") dla _, e := zakres e-maile { fmt.Wydrukuj(Temat) } }
Czas rzeczywisty

Czytanie e-maili w czasie rzeczywistym: Webhooki a polling

Świadomość nadejścia nowego e-maila jest równie ważna jak możliwość jego odczytania. Dostępne są trzy mechanizmy, każdy z bardzo różnymi charakterystykami działania w szerokiej skali.

Unikaj na dużą skalę

Sondaż

Twoja aplikacja wywołuje punkt końcowy listy e-maili w określonych odstępach czasu (co 30 sekund, co 5 minut). Proste do zaimplementowania, ale zużywa limit, wprowadza opóźnienia i nie skaluje się poza garstką kont.

Proste - bez konfiguracji po stronie serwera
Podatek API proporcjonalny do kont x częstotliwość
Ankieta 5-minutowa = 5-minutowe opóźnienie powiadomienia
Nie skaluje się powyżej ~100 aktywnych kont
Specyficzne dla dostawcy

Natywne Webhooky Dostawcy

Powiadomienia Gmail Pub/Sub i Microsoft Graph wypychają zdarzenia na twój serwer natychmiast. Szybkie i wydajne pod względem limitów – ale każde wymaga oddzielnej konfiguracji, oddzielnej logiki odnawiania i innych schematów zdarzeń.

Dostawa w niemal błyskawicznym tempie (sekundy)
Wydajny pod względem limitu - aktywowany tylko dla nowych wiadomości e-mail
Gmail: subskrypcja Pub/Sub wygasa co 7 dni
Wykres: subskrypcja maks. ~3 dni, musi zostać odnowiona
IMAP IDLE: 1 połączenie TCP na konto
Zalecane

Unipile Zunifikowane Webhooki

Unipile abstrahuje wszystkie mechanizmy push dostawców za jednym email.received zdarzenie. Jedno z punktów końcowych odbiera powiadomienia z kont Gmail, Outlook i IMAP, a automatyczne odnawianie subskrypcji jest obsługiwane wewnętrznie.

Jeden adres URL webhooka dla wszystkich dostawców
Automatyczne odnawianie Pub/Sub i grafu
IMAP IDLE zarządzane wewnętrznie per konto
Znormalizowana ładunek - zawsze te same pola
Jak Unipile abstrahuje w czasie rzeczywistym dostarczanie wiadomości e-mail

Pod maską, Unipile zarządza subskrypcjami Gmail Pub/Sub, subskrypcjami powiadomień o zmianach Microsoft Graph oraz połączeniami IMAP IDLE – dla każdego połączonego konta, automatycznie odnawianymi. Twoja aplikacja rejestruje jeden adres URL webhook i otrzymuje jedno znormalizowane zdarzenie, niezależnie od dostawcy.

Gmail Pub/Sub
+
Subskrypcje grafów
+
IMAP IDLE
->
zdarzenie.otrzymano.email
Bezpieczeństwo i zgodność

Bezpieczeństwo i zgodność podczas czytania e-maili użytkowników

Dostęp do e-maili użytkowników wiąże się ze znacznymi obowiązkami w zakresie bezpieczeństwa i prawa. Oto cztery obszary, które musisz uwzględnić przed wdrożeniem integracji z interfejsem API odczytu poczty e-mail do produkcji.

Minimalizacja zakresu OAuth

Zawsze żądaj minimalnego wymaganego zakresu OAuth. Do odczytu wiadomości e-mail użyj zakresy tylko do odczytu - Nigdy nie proś o uprawnienia do wysyłania lub tworzenia, jeśli Twoja aplikacja potrzebuje tylko dostępu do skrzynki odbiorczej. Zakres tylko do odczytu dla Gmaila to gmail.tylko_do_odczytu. Odpowiednikiem Microsoft Graph jest Mail.Read. Żądanie szerokich zakresów inicjuje bardziej rygorystyczne procesy przeglądu w Google i Microsoft oraz zmniejsza zaufanie użytkowników na ekranie zgody.

Najlepsze praktyki przechowywania tokenów

Tokeny dostępu OAuth i tokeny odświeżania to poświadczenia. Przechowuj je zaszyfrowane podczas przechowywania Używaj AES-256 lub równoważnego, nigdy w postaci zwykłego tekstu w swojej bazie danych. Rotuj klucze szyfrowania cyklicznie. Nigdy nie loguj tokenów w logach aplikacji. Wdróż odwoływanie tokenów, gdy użytkownik rozłączy swoje konto – wywołaj punkt końcowy odwoływania dostawcy, nie usuwaj po prostu rekordu bazy danych.

RODO i rezydencja danych

Treść wiadomości e-mail często zawiera dane osobowe objęte RODO. Musisz udokumentować w swojej polityce prywatności dokładnie, jakie dane dotyczące poczty e-mail gromadzisz, przechowujesz, przetwarzasz i przez jaki czas. Wdróż proces usuwania danych, który usuwa treść wiadomości e-mail na żądanie użytkownika dotyczące usunięcia. Jeśli przechowujesz treść wiadomości e-mail we własnej infrastrukturze, rozważ wymogi dotyczące rezydencji danych dla klientów z UE.

Weryfikacja Google CASA i Microsoft Publisher

Aplikacje proszące o wrażliwe zakresy Gmail (w tym gmail.tylko_do_odczytu) musi ukończyć Google CASA Poziom 2 ocena bezpieczeństwa przed dopuszczeniem do testów powyżej limitu 100 użytkowników. Microsoft wymaga weryfikacji wydawcy dla aplikacji żądających określonych zakresów Graph. Oba procesy trwają tygodnie — zaplanuj je z uwzględnieniem daty premiery. Korzystanie z Unipile dziedziczy te certyfikaty z warstwy platformy.

Certyfikaty zgodności Unipile

Unipile obsługuje certyfikację Gmail CASA Tier 2, Microsoft Publisher Verification, audyt SOC 2 Type II i umowy o przetwarzaniu danych RODO na poziomie platformy. Produkty zbudowane na bazie Unipile dziedziczą te certyfikaty, zamiast przechodzić je niezależnie.

SOC 2 Typ II
Google CASA Poziom 2
Zgodność z RODO
Uprawnienia OAuth 2.0 tylko do odczytu
Wycena

Cennik API do odczytu wiadomości e-mail: Poziomy darmowe i modele kosztów

Darmowe poziomy API natywnych dostawców są hojne przy niskim obciążeniu, ale ukryte koszty pojawiają się, gdy trzeba obsługiwać wielu dostawców, zarządzać odświeżaniem tokenów na dużą skalę lub osiągać limity żądań. Oto szczere podsumowanie.

Dostawca Darmowy poziom Model kosztów Limit żądanych danych Ukryte koszty
Gmail API Bezpłatnie z limitami Liczba jednostek w ramach limitu na jedno zgłoszenie. Brak rozliczeń na konto 250 jednostek/sek/użytkownika, 1 miliard jednostek/dzień Recenzja CASA Tier 2, parsowanie MIME, logika odnowienia Pub/Sub
Microsoft Graph Darmowe z ograniczoną prędkością Dołączony do dzierżawy Microsoft 365. Brak opłaty za połączenie 10 000 żądań na 10 minut na aplikację na dzierżawcę Proces weryfikacji wydawcy, odnowienie subskrypcji, aplikacje OAuth na najemcę
IMAP (hostowany lokalnie) Wolny protokół Brak kosztów API. Koszty infrastruktury dla pul połączeń Dostawca-specyficzne, ~10-20 połączeń/konto Infrastruktura serwerowa, zarządzanie połączeniami IDLE, brak obsługi push
Unipile 7-dniowy bezpłatny okres próbny Za powiązane konto miesięcznie. Zobacz bezpłatna warstwa API poczty e-mail Zarządzane wewnętrznie, wbudowana logika ponawiania prób Koszt wywołania API na konto – skompensowany przez wyeliminowanie inżynierii OAuth/MIME
Gmail API
Bezpłatnie z limitami
Model kosztów Liczba jednostek w ramach limitu na jedno zgłoszenie. Brak rozliczeń na konto
Limit żądanych danych 250 jednostek/sek/użytkownika, 1 miliard jednostek/dzień
Ukryte koszty Recenzja CASA Tier 2, parsowanie MIME, logika odnowienia Pub/Sub
Microsoft Graph
Darmowe z ograniczoną prędkością
Model kosztów Dołączony do dzierżawy Microsoft 365. Brak opłaty za połączenie
Limit żądanych danych 10 000 żądań na 10 minut na aplikację na dzierżawcę
Ukryte koszty Proces weryfikacji wydawcy, odnowienie subskrypcji, aplikacje OAuth na najemcę
IMAP (hostowany lokalnie)
Wolny protokół
Model kosztów Brak kosztów API. Koszty infrastruktury dla pul połączeń
Limit żądanych danych Dostawca-specyficzne, ~10-20 połączeń/konto
Ukryte koszty Infrastruktura serwerowa, zarządzanie połączeniami IDLE, brak obsługi push
Unipile
7-dniowy bezpłatny okres próbny
Model kosztów Za powiązane konto miesięcznie. Zobacz bezpłatna warstwa API poczty e-mail
Limit żądanych danych Zarządzane wewnętrznie, wbudowana logika ponawiania prób
Ukryte koszty Koszt wywołania API na konto – skompensowany przez wyeliminowanie inżynierii OAuth/MIME
Powszechne pułapki

Typowe pułapki przy budowaniu integracji czytania e-maili

Oto błędy, które konsekwentnie powodują incydenty produkcyjne w zespołach wdrażających swoją pierwszą integrację z API do odczytu wiadomości e-mail. Poznaj je, zanim je napotkasz.

01
Wykorzystanie limitów w Gmailu na dużą skalę

Limit Gmaila wynoszący 250 jednostek kwotowych na sekundę na użytkownika brzmi hojnie, dopóki nie masz 500 kont i nie musisz przeprowadzić początkowej synchronizacji skrzynki pocztowej. Wyświetlenie 500 wiadomości kosztuje 2500 jednostek; pobranie każdej pełnej wiadomości kosztuje kolejne 2500. Początkowe synchronizacje dużych skrzynek pocztowych mogą wyczerpać dzienne kwoty w ciągu kilku godzin.

Napraw Zaimplementuj wykładnicze wycofywanie w odpowiedziach 429, priorytetyzuj najnowsze wiadomości do początkowej synchronizacji i używaj zbiorczych żądań tam, gdzie są dostępne, aby zmniejszyć narzut na jedno wywołanie.
02
Ciche błędy odświeżania tokenu

Tokeny odświeżania OAuth wygasają w sposób niezauważalny - Google unieważnia je po 6 miesiącach nieaktywności, po zmianie hasła lub gdy użytkownik cofnie dostęp w ustawieniach swojego Konta Google. Jeśli logika odświeżania tokenów nie wykryje błędu 401 i nie wyświetli go użytkownikowi, aplikacja po prostu przestanie odczytywać e-maile bez widocznego błędu.

Napraw Potraktuj odpowiedzi 401 jako zdarzenia rozłączenia konta. Powiadom użytkownika i poproś o ponowne uwierzytelnienie. Zapisz ostatnia_synchronizacja znacznik czasu oraz powiadomienie, gdy przekroczy on ustawiony interwał synchronizacji.
03
Brakujące e-maile z powodu nieprawidłowych filtrów folderów

Etykiety Gmail i foldery IMAP nie są koncepcjami równoważnymi. Gmail INBOX Etykieta nie obejmuje wiadomości, które zostały zarchiwizowane (usunięte ze skrzynki odbiorczej, ale nie skasowane). Folder skrzynki odbiorczej w usłudze Microsoft Graph nie uwzględnia skrzynki odbiorczej z priorytetami w porównaniu z innymi podziałami okien, chyba że wyszukuje się obie te pozycje. Użytkownicy aplikacji Teams często stwierdzają, że brakuje im 20–40% wiadomości z powodu błędnych założeń dotyczących folderów.

Napraw Przetestuj zapytania folderów z rzeczywistymi kontami, w tym z zaszyfrowanymi, filtrowanymi i skategoryzowanymi wiadomościami. Aby uzyskać kompleksową synchronizację, rozważ zapytania WSZYSTKO wiadomości (nie tylko SKRZYNKA ODBIORCZA) i filtrowanie według daty po twojej stronie.
04
Błędy kodowania w międzynarodowych wiadomościach e-mail

Treść wiadomości e-mail dociera w szerokim zakresie kodowań znaków: UTF-8, ISO-8859-1, Windows-1252, Shift-JIS. Gmail zwraca części zakodowane w base64url. IMAP zwraca części zakodowane w quoted-printable. Dekodowanie jednego kodowania jako innego powoduje uszkodzenie tekstu wiadomości, który jest niewidoczny w Twoim lokalnym środowisku testowym (które prawdopodobnie wysyła tylko e-maile w kodowaniu ASCII).

Napraw Zawsze dekoduj części MIME zgodnie z ich Content-Transfer-Encoding i przekoduj do UTF-8. Testuj szczególnie z treściami e-maili zawierających język japoński, arabski i emoji.
05
Niespójności w wątkach między dostawcami

Zbudowanie jednolitego widoku wątków obejmującego konta Gmail, Outlook i IMAP wymaga normalizacji trzech zupełnie różnych modeli wątków. Gmail posiada natywne identyfikatory wątków. Outlook ma identyfikatory konwersacji, które działają inaczej. IMAP nie ma natywnych wątków – wątki odtwarza się na podstawie Identyfikator wiadomości, Bibliografiaoraz Odpowiedź-Do nagłówki, które nie zawsze są obecne lub poprawne.

Napraw Zjednoczone API do odczytu poczty e-mail, takie jak Unipile, normalizuje wątki w spójny model we wszystkich dostawcach, eliminując potrzebę implementacji specyficznej dla dostawcy logiki rekonstrukcji wątków.
FAQ

Przeczytaj Email API - Często zadawane pytania

Najczęściej zadawane pytania przez programistów tworzących swoją pierwszą integrację z API do odczytu wiadomości e-mail.

01
Co to jest interfejs API do odczytu wiadomości e-mail?
A odczytaj API poczty e-mail jest interfejsem HTTP, który pozwala Twojej aplikacji na uwierzytelnienie się w istniejącej skrzynce pocztowej użytkownika (za pomocą OAuth 2.0 lub danych uwierzytelniających IMAP) i programowe pobieranie wiadomości e-mail. Różni się od transakcyjnych interfejsów API do poczty e-mail, takich jak SendGrid lub Mailgun, które wysyłają wychodzącą pocztę e-mail z domeny, którą kontrolujesz. Interfejsy API do czytania poczty e-mail działają na własnym koncie Gmail, Outlook lub IMAP użytkownika. Zobacz pełne porównanie dostawców interfejsu API poczty e-mail dla kontekstu szerszego ekosystemu.
02
Czy mogę odczytać czyjś e-mail za pomocą API?
Możesz odczytywać e-maile tylko z kont, dla których właściciel skrzynki pocztowej wyraźnie udzielił Twojej aplikacji dostępu za pośrednictwem zgody OAuth 2.0. Użytkownik musi autoryzować Twoją aplikację na ekranie zgody Google lub Microsoft. Nie możesz uzyskać dostępu do e-maili bez zgody właściciela konta – próba zrobienia tego narusza warunki świadczenia usług dostawcy i obowiązujące prawo w większości jurysdykcji.
03
Jak czytać wiadomości e-mail za pomocą interfejsu API Gmail?
Aby czytać e-maile za pomocą Gmail API: utwórz projekt Google Cloud, włącz Gmail API, skonfiguruj klienta OAuth 2.0, zażądaj gmail.tylko_do_odczytu zakres, uzyskaj token dostępu za pośrednictwem zgody OAuth, a następnie wywołaj POBIERZ /gmail/v1/users/me/messages do wyświetlania wiadomości i GET /users/me/messages/{id}?format=full do pobrania poszczególnych wiadomości e-mail. Wiadomości są zwracane jako części MIME zakodowane w base64url, które należy zdekodować.
04
Czym różni się IMAP od API Gmaila?
API Gmail to nowoczesne REST API z obsługą OAuth 2.0, powiadomieniami push za pośrednictwem Google Pub/Sub i odpowiedziami w formacie JSON. IMAP to uniwersalny protokół TCP obsługiwany przez każdego dostawcę poczty e-mail, wykorzystujący stany połączenia i polecenia tekstowe. API Gmail jest bardziej wszechstronne w przypadkach użycia ograniczonych do Gmaila (powiadomienia w czasie rzeczywistym, dostęp do wątków, zarządzanie etykietami). IMAP zapewnia uniwersalne pokrycie wszystkich dostawców, ale wymaga odpytywania lub połączeń IDLE i nie ma natywnego interfejsu REST. Przeczytaj nasze Przewodnik po integracji API IMAP dla głębszego porównania.
05
Czy istnieje darmowe API do odczytu wiadomości e-mail?
Tak. Gmail API jest bezpłatny w ramach limitów kwotowych Google (250 jednostek/sek/użytkownik, 1 miliard jednostek/dzień). Microsoft Graph dla Outlook jest bezpłatny z ograniczeniami przepustowości. IMAP to bezpłatny otwarty protokół. W przypadku obsługi wielu dostawców, Unipile oferuje 7-dniowy bezpłatny okres próbny obejmujący konta Gmail, Outlook i IMAP. Zobacz nasze bezpłatny przewodnik po API e-mail aby uzyskać pełne porównanie bezpłatnych poziomów i ich rzeczywistych limitów.
06
Jak odczytać e-maile od wielu dostawców za pomocą jednego API?
Użyj ujednoliconego API do odczytu wiadomości e-mail, takiego jak Unipile. Unipile udostępnia pojedynczy punkt końcowy (POBIERZ /api/v1/emails) zwracający znormalizowane dane JSON dla kont Gmail, Outlook i IMAP. Użytkowników uwierzytelniasz jednokrotnie za pomocą hostowanego linku OAuth, a Unipile zajmuje się specyficznymi dla dostawcy przepływami OAuth, parsowaniem MIME i abstrakcją webhooków w czasie rzeczywistym za jednym spójnym interfejsem. Zobacz nasz Przewodnik po interfejsie API poczty e-mail do pełnego odniesienia.
07
Czy mogę odczytywać załączniki e-maili za pomocą API?
Tak. Gmail API zwraca metadane załączników w ładunku wiadomości i udostępnia oddzielny punkt końcowy do pobierania danych załączników według identyfikatora. Microsoft Graph zwraca załączniki za pomocą /wiadomości/{id}/załączniki. IMAP wymaga parsowania drzewa MIME w celu identyfikacji części załączników. W przypadku Unipile metadane załączników (nazwa pliku, rozmiar, typ MIME) są zawarte w odpowiedzi e-mail, a zawartość załączników jest dostępna za pośrednictwem dedykowanego punktu końcowego – nie jest wymagane parsowanie MIME.
08
Jak otrzymywać powiadomienia o nadejściu nowych wiadomości e-mail?
Każdy dostawca posiada inny mechanizm: Gmail wykorzystuje subskrypcje push Google Pub/Sub (wygasają co 7 dni, wymagają odnowienia). Microsoft Graph wykorzystuje subskrypcje powiadomień o zmianach (wygasają po około 3 dniach). IMAP wykorzystuje komendę IDLE przez stałe połączenie TCP. Alternatywnie, Unipile abstrahuje wszystkie trzy w jeden email.received zdarzenie webhook aktywowane dla kont Gmail, Outlook i IMAP z automatycznym zarządzaniem subskrypcjami obsługiwanym wewnętrznie.
09
Jakie są limity szybkości odczytu wiadomości e-mail w Gmailu i Outlooku?
Gmail API: 250 jednostek kwoty na użytkownika na sekundę. Wymienianie wiadomości kosztuje 5 jednostek, pobieranie pełnej wiadomości kosztuje 5 jednostek. Dzienne ograniczenie wynosi 1 miliard jednostek kwoty. Microsoft Graph: 10 000 żądań na każde 10 minut na aplikację na klienta. Oba zwracają kod HTTP 429 w przypadku przekroczenia limitu, z liczbą Ponów-Po Nagłówek. Wprowadź wykładnicze wycofywanie z losowością (jitter) dla niezawodności produkcyjnej. Limity IMAP są specyficzne dla dostawcy, zazwyczaj 10-20 jednoczesnych połączeń na konto.
10
Czy czytanie e-maili użytkowników przez API jest zgodne z RODO?
Czytanie e-maili użytkowników za pośrednictwem API może być zgodne z RODO, jeśli jest prawidłowo zaimplementowane. Wymagania obejmują: wyraźną zgodę użytkownika za pośrednictwem OAuth (ekran zgody spełnia wymóg podstawy prawnej), politykę prywatności dokumentującą, jakie dane z e-maili zbierasz i przechowujesz, mechanizm usuwania danych na potrzeby żądań usunięcia oraz umowę o przetwarzaniu danych z wszelką warstwą API stron trzecich, z której korzystasz. Unipile posiada certyfikat SOC 2 Type II i jest zgodny z RODO, upraszczając dokumentację zgodności dla produktów zbudowanych na platformie.

Masz jeszcze jakieś pytania? Porozmawiaj z programistą, który wdrożył integracje API do odczytu poczty e-mail na dużą skalę dla Gmail, Outlook i IMAP.

Porozmawiaj z ekspertem
pl_PLPL