Your account is ready.
" }' ``` Éles kódba ne égesd bele az API kulcsokat. Tárold a titkokat titokkezelőben vagy környezeti változóban, forgasd őket, korlátozd a hozzáférést, és soha ne tedd ki őket a frontend kódba. ## Éles e-mail API architektúra *The webhook writes back to the record that sent it* Egy éles e-mail API integráció ne küldjön közvetlenül minden kontrollerből vagy útvonalkezelőből. Használj egy vékony üzenetréteget: 1. Bekövetkezik a termékesemény. 2. Az alkalmazás sorba, jobba vagy eseménybuszra írja az eseményt. 3. Az e-mail szolgáltatás sablonra képezi le az eseményt. 4. Az e-mail szolgáltatás ellenőrzi a címzett hozzájárulását és a kizárási szabályokat. 5. Az e-mail szolgáltatás meghívja a szolgáltató API-ját. 6. Az e-mail szolgáltatás elmenti a szolgáltatói üzenetazonosítót. 7. A webhookok később frissítik az üzenet státuszát. Így tiszta marad a termékkód, és a levelezési hibákat könnyebb elszigetelni. Ajánlott belső mezők: - `event_id`. - `message_type`. - `recipient_id`. - `recipient_email`. - `template_id`. - `locale`. - `provider`. - `provider_message_id`. - `idempotency_key`. - `status`. - `error_code`. - `created_at`. - `sent_at`. - `delivered_at`. A kritikus üzenetekhez használj idempotenciakulcsot. Egy újrapróbálkozás ne küldjön három jelszó-visszaállító levelet csak azért, mert a hálózati kérés időtúllépéssel elszállt, miután a szolgáltató már elfogadta az elsőt. ## A legjobb e-mail API-k összehasonlítva ### Brevo A Brevo akkor hasznos, ha a tranzakciós e-mail egy tágabb ügyfélkommunikációs rendszer része. Akkor válaszd a Brevót, ha: - Tranzakciós e-mail mellett kampányok, CRM, automatizálás, SMS vagy WhatsApp is kell. - Az e-kereskedelmi adatoknak életciklus-üzeneteket kell indítaniuk. - A marketing- és termékkommunikációnak közös kapcsolati profilokra van szüksége. - Nem fejlesztőknek is hozzá kell férniük a sablonokhoz és a riportokhoz. - Egy platformot akarsz csatornánként külön pontmegoldások helyett. Figyelj ezekre: - A marketing- és a tranzakciós e-mail beállításai közti különbség. - A sablonok tulajdonlása fejlesztés és marketing között. - A sebességkorlátok és a csomagok korlátai. - Ahogyan a kapcsolati adatok szinkronizálódnak. - Ahogyan a leiratkozási és kizárási szabályok az egyes üzenetkategóriákra vonatkoznak. A Brevo dokumentációja lefedi a tranzakciós küldést, a kötegelt küldést, a sandbox módot, az SMTP relayt, a webhookokat, az SDK-kat és az API-referenciát. Az implementációs részletekhez ezeket használd. ### SendGrid A SendGrid gyakori választás azoknak a csapatoknak, amelyek érett fejlesztői e-mail API-t akarnak széles nyelvi és platformtámogatással. Akkor válaszd a SendGridet, ha: - A fejlesztők ismerős e-mail API-t és SDK-ökoszisztémát akarnak. - Tranzakciós és marketing e-mail is kell ugyanattól a szállítótól. - Már van Twilio infrastruktúrád. - Esemény-webhookokra és részletes küldési vezérlésre van szükséged. Figyelj ezekre: - Mely kézbesíthetőségi és támogatási funkciók járnak a választott csomaghoz. - Hogyan kezeled a sablonokat a különböző környezetek között. - Osztozzon-e a marketing és a tranzakciós e-mail ugyanazon a fiókszerkezeten. ### Mailgun A Mailgun a fejlesztők vezette küldésre és az API-first munkafolyamatokra épül. Akkor válaszd a Mailgunt, ha: - A mérnökcsapaté az e-mail infrastruktúra. - HTTP küldés, SMTP tartalék, naplók, bejövő útvonalak és validációs eszközök kellenek. - Olyan szolgáltatót akarsz, amelyik nyíltan beszél a kézbesíthetőség üzemeltetéséről. Figyelj ezekre: - Mely validációs, analitikai és kézbesíthetőségi funkciók járnak. - Az adatmegőrzés és a naplókhoz való hozzáférés. - A támogatási elvárások a migráció és a bemelegítés alatt. ### Amazon SES Az Amazon SES infrastruktúra-szemléletű. Akkor válaszd az Amazon SES-t, ha: - Az alkalmazásod már erősen AWS-en fut. - Van mérnöki kapacitásod a beállítás nagyobb részének átvállalására. - Nagy volumenű, használatalapú küldésre van szükséged. - Szoros integrációt akarsz az IAM, a CloudWatch, az SNS, a Lambda vagy más AWS szolgáltatások felé. Figyelj ezekre: - A sandboxból való kiengedés és az éles hozzáférés. - A domainidentitás beállítása. - A visszapattanások és panaszok kezelése. - A dedikált IP-ről szóló döntés. - A monitorozás és a riasztás. - Annak a fejlesztői költsége, hogy felépíted azt, amit más szolgáltatók készen adnak a felületükön. A SES nagy volumenen kiváló lehet, de nem minden csapatnak ez a legkisebb erőfeszítésű választás. ### Postmark A Postmark a tranzakciós e-mailre fókuszál. Akkor válaszd a Postmarkot, ha: - A tranzakciós megbízhatóság és az áttekinthetőség fontosabb, mint a mindent egyben marketing. - Olyan üzenetfolyamokat akarsz, amelyek szétválasztják az e-mail típusokat. - Sablonok, bejövő levél és kézbesítési események kellenek egy letisztult termékben. Figyelj ezekre: - Az árazási szintek a te volumeneden. - Meddig kell megőrizni az eseményeket és az üzeneteket. - A tömeges marketing külön folyamba vagy külön platformra való-e. ## Mikor használj e-mail API-t ### Tranzakciós levelek A tranzakciós levelet felhasználói cselekvés vagy rendszeresemény indítja. Példák: - Fiók megerősítése. - Magic link bejelentkezés. - Jelszó-visszaállítás. - Kétlépcsős azonosítás. - Termékmeghívó. - Rendelés visszaigazolása. - Fizetési nyugta. - Szállítási visszaigazolás. - Kézbesítési frissítés. - Visszatérítési értesítő. - Előfizetés megújítása. - Sikertelen fizetés riasztása. - Biztonsági értesítés. A tranzakciós levéltől nagy megbízhatóságot várnak. A felhasználó azonnal észreveszi, ha nem érkezik meg a bejelentkezési link, a nyugta vagy a jelszó-visszaállító levél. Lásd még: [rendelés-visszaigazoló levelek](https://tajo.io/hu/blog/order-confirmation-email-guide/) és [tranzakciós e-mail példák](https://tajo.io/hu/blog/transactional-email-examples/). ### Termék-életciklus levelek Az életciklus-levelek a tranzakciós és a marketing között helyezkednek el. Példák: - Próbaidőszak bevezetése. - Funkció aktiválása. - Használati mérföldkő. - Ösztönzés a bővítésre. - Emlékeztető inaktív fiókra. - Ügyfélsiker-egyeztetés. - Megújítási sorozat. - Visszanyerő üzenet. Ezek akkor működnek a legjobban, ha termékadat indítja őket, nem egy általános naptár. ### E-kereskedelmi levelek Az e-kereskedelmi csapatoknak gyakran tranzakciós és marketing által indított levél is kell: - Üdvözlő ajánlat. - Elhagyott kosár. - Böngészés elhagyása. - Újra raktáron. - Árcsökkenés. - Termékajánló. - Utántöltési emlékeztető. - Hűségprogram-frissítés. - Vélemény kérése. - VIP korai hozzáférés. ### Marketinglevelek API-n keresztül Ne kezeld a marketing e-mailt csak kötegelt hírlevélfeladatként. Az API által indított marketing támogathat: - Eseményalapú szegmentálást. - Személyre szabott kampányokat. - Triggerelt [drip sorozatokat](https://tajo.io/hu/blog/drip-campaign-guide/). - Termékvezérelt bevezetést. - Fiókalapú életciklus-utakat. - A vásárlói viselkedéshez kötött [automatizált e-mailt](https://tajo.io/hu/blog/automated-email-guide/). A megfelelőségi elvárás itt is él. A marketingüzenethez megfelelő hozzájárulás, leiratkozáskezelés és kizárási szabály kell. ## Milyen API-funkciókat keress ### Hitelesítés és kulcskezelés Egy komoly e-mail API biztonságos API kulcsokat és világos hitelesítési dokumentációt ad. Üzemeltetési követelmények: - Környezetenként külön kulcs. - Korlátozott hozzáférés az éles kulcsokhoz. - Kulcsforgatás. - Kulcsok tárolása a kódon kívül. - A kulcshasználat naplózása a kulcs értéke nélkül. - A kulcsok eltávolítása a hibás kérések kiírásaiból. ### Sablonok A sablonok tartják egységesen a tranzakciós levelet. Keresd: - Verziózás. - Tesztküldés. - Változók. - Tartalék értékek. - Lokalizáció. - Előnézeti renderelés. - Jóváhagyási folyamatok. - Külön staging és éles sablonok. A sablon nem csak dizájnelem. A termékígéret része. Egy jelszó-visszaállító, rendelés-visszaigazoló vagy számlasablont ugyanolyan komolyan kell átnézni, mint az alkalmazás felületét. ### Webhookok A webhookok visszacsatolássá alakítják a küldést. Kövesd: - Feldolgozva. - Halasztva. - Kézbesítve. - Megnyitva, óvatosan. - Kattintva, óvatosan. - Visszapattant. - Eldobva. - Panasz érkezett. - Leiratkozott. Tárold a szolgáltatói üzenetazonosítókat, hogy a webhookeseményeket hozzá tudd rendelni a belső felhasználókhoz és eseményekhez. ### Kizáráskezelés A kizáráskezelés védi a kézbesíthetőséget és a megfelelőséget. A rendszernek kezelnie kell: - Hard bounce eseteket. - Panaszokat. - Leiratkozásokat. - Kézi tiltásokat. - A szerepalapú címeket, ha a szabályzatod kizárja őket. - Érvénytelen kapcsolatokat. - Fióktörlési vagy adatvédelmi kéréseket. Soha ne próbálkozz újra végtelenül egy véglegesen sikertelen címmel csak azért, mert a termékkód a levélküldést háttérfeladatnak látja. ### Sebességkorlátok és átbocsátás Nézd meg, hogyan kezeli a szolgáltató: - Az API kérések korlátait. - Az üzenet-átbocsátást. - A kötegelt végpontokat. - A csúcskorlátokat. - A napi vagy havi csomagkorlátokat. - Az új fiók bemelegítését. - A dedikált IP bemelegítését. Tervezz a csúcsokra. Egy termékbevezetés, egy jelszó-visszaállítási incidens, egy Black Friday akció vagy egy biztonsági értesítés a napi átlag sokszorosát hozhatja. ### Analitika és exportok Minimális riportigény: - Elküldve. - Kézbesítve. - Visszapattant. - Halasztva. - Panaszok. - Leiratkozások. - Sablonteljesítmény. - Szolgáltatói hibaválaszok. - Bevételi vagy konverziós események, ahol relevánsak. A megnyitásokat és a kattintásokat kezeld óvatosan. Az adatvédelmi megoldások, a képblokkolás és a botforgalom torzítják az elköteleződési adatokat. Tranzakciós levélnél a kézbesítés és a sikeres felhasználói cselekvés gyakran fontosabb, mint a megnyitási arány. ### Bejövő levelek feldolgozása A bejövő levél akkor számít, ha a felhasználók válaszolnak, vagy tartalmat küldenek a termékbe. Használati esetek: - Ügyfélszolgálati válaszok. - E-mailből ticket. - Válasz hozzászólásra. - Jóváhagyási folyamatok. - Továbbított nyugták. - Bejövő érdeklődők rögzítése. Ha a bejövő feldolgozás szerepel a tervekben, olyan szolgáltatót válassz, amelynek világos a dokumentációja, az útválasztása, a biztonsági vezérlése és a mellékletkezelése. ## Kézbesíthetőség e-mail API-val Az API önmagában nem oldja meg a kézbesíthetőséget. Továbbra is kell: - SPF. - DKIM. - DMARC. - Ellenőrzött küldő domainek. - Következetes feladói azonosság. - Tiszta listák. - Visszapattanások kezelése. - Panaszok kezelése. - Világos leiratkozás a marketingüzeneteknél. - Releváns tartalom. - Ésszerű küldési gyakoriság. - Monitorozás. Új domaint vagy IP-t fokozatosan melegíts be. Kezdd alacsony kockázatú, magas elköteleződésű levéllel, és a reputáció stabilizálódásával növeld a volument. Ahol lehet, válaszd szét az üzenettípusokat: - Hitelesítés és biztonság. - Nyugták és rendelési frissítések. - Termék-életciklus. - Marketing. - Tömeges promóciók. Ne engedd, hogy egy agresszív promóciós kampány elrontsa a jelszó-visszaállítók vagy a nyugták kézbesítését. ## Hibakezelés és újrapróbálkozás Az e-mail API hibáit osztályozni kell. Próbáld újra: - Időtúllépés. - Átmeneti szolgáltatói hiba. - Sebességkorlát, késleltetés után. - Hálózati hiba. - Átmeneti sorproblémák. Ne próbáld újra a végtelenségig: - Érvénytelen címzett. - Jogosulatlan API kulcs. - Érvénytelen sablonazonosító. - Hiányzó kötelező mező. - Kizárt címzett. - Szabályzati vagy megfelelőségi tiltás. Használj exponenciális visszalépést és dead letter sort azokra az üzenetekre, amelyek az újrapróbálkozások után is elbuknak. Minden kritikus levélhez legyen üzemeltetési út: - Újra tudja küldeni az ügyfélszolgálat? - Kérheti újra a felhasználó? - Vissza tudja követni a fejlesztés az eseményt? - Látod a szolgáltató válaszát? - Be tudod bizonyítani, hogy a szolgáltató elfogadta-e? ## E-mail API bevezetési ellenőrzőlista Indulás előtt vedd végig ezt a listát. 1. Válaszd ki az üzenettípusokat és a felelősöket. 2. Válassz API szolgáltatót és tartalék megoldást. 3. Ellenőrizd a küldő domaineket. 4. Állítsd be az SPF, DKIM és DMARC rekordokat. 5. Hozz létre staging és éles API kulcsokat. 6. Tárold biztonságosan a titkokat. 7. Építs üzenetszolgáltatást vagy adaptert. 8. Adj hozzá idempotenciakulcsokat. 9. Adj hozzá strukturált naplókat. 10. Építsd meg az újrapróbálkozást és a dead letter működést. 11. Készítsd el a sablonokat. 12. Teszteld a személyre szabást és a tartalék értékeket. 13. Állítsd be a webhookokat. 14. Tárold a szolgáltatói üzenetazonosítókat. 15. Kezeld a visszapattanásokat, a panaszokat és a leiratkozásokat. 16. Építs ügyfélszolgálati eszközt az újraküldéshez és a státuszkereséshez. 17. Figyeld a hibaarányt és a kézbesítési arányt. 18. Dokumentáld a sebességkorlátokat és az incidenskezelési forgatókönyveket. ## Szolgáltatóválasztó pontozólap Pontozz minden szállítót 1-től 5-ig: | Szempont | Súly | Miért számít | | --- | --- | --- | | Kézbesíthetőségi eszközök | 5 | Az olcsó API drága, ha a levél nem érkezik meg | | API dokumentáció | 5 | A fejlesztőknek gyors és pontos implementáció kell | | Webhookok | 5 | A termékcsapatnak kézbesítési és hibavisszajelzés kell | | Kizáráskezelés | 5 | Védi a megfelelőséget és a feladói reputációt | | Sablonok | 4 | Csökkenti a termék és a marketing közti elcsúszást | | SDK-k | 3 | Gyorsítja a bevezetést a stackedben | | Árazási modell | 4 | A költség nagy volumenen gyorsan változhat | | Támogatás | 4 | Az e-mail incidenseket az ügyfelek is látják | | Adatmegőrzés | 3 | Hat a hibakeresésre és a támogatásra | | Bejövő feldolgozás | 2 | Csak válaszalapú folyamatoknál kritikus | | Többcsatornás illeszkedés | 3 | Hasznos, ha az e-mail összeér az SMS-sel, a WhatsApppal, a CRM-mel vagy az automatizálással | Sok csapatnál a helyes válasz nem a legolcsóbb e-mail API. Az a szolgáltató a jó, amelyik csökkenti az üzemeltetési kockázatot azoknál a leveleknél, amelyekre az ügyfeleid támaszkodnak. ## Gyakori hibák Kerüld: - A küldést szétszórtan, közvetlenül az alkalmazás kódjából. - Az API kulcsok vagy a teljes, személyes adatot tartalmazó törzsek naplózását. - Minden hiba újrapróbálását úgy, mintha átmeneti lenne. - A szolgáltatói üzenetazonosítók figyelmen kívül hagyását. - A webhookok halogatását addig, amíg az ügyfélszolgálat rá nem kérdez, hogy megérkezett-e a levél. - A jelszó-visszaállítók és a tömeges marketing keverését ugyanazon a reputációs úton. - Egyetlen sablon használatát minden nyelvhez. - A sablonváltozók tartalék értékeinek kihagyását. - A megnyitás kezelését a kézbesítés vagy az ügyfélsiker bizonyítékaként. - Azt, hogy a marketing leiratkozási logikája tudatos szabályzat nélkül elnyomja a kötelező fiókbiztonsági üzeneteket. - A szolgáltatók összehasonlítását csak az ingyenes csomag alapján. - A nagy volumenű indulást bemelegítés nélkül. ## Hogyan kezdj hozzá Új bevezetésnél válaszd a legrövidebb biztonságos utat: 1. Kezdd egyetlen tranzakciós üzenettel, például a jelszó-visszaállítással vagy a rendelés visszaigazolásával. 2. Építs szolgáltatói adaptert ahelyett, hogy a termékkódot egy szállítóhoz kötnéd. 3. Add hozzá a domainhitelesítést. 4. Add hozzá a webhookos státuszkövetést. 5. Add hozzá az ügyfélszolgálati láthatóságot. 6. Add hozzá a sablonokat és a lokalizációt. 7. Terjeszd ki életciklus- és e-kereskedelmi automatizálásokra. Ha a csapatod már Brevót használ marketingre és CRM-re, kezdd a Brevo tranzakciós API-jával, és képezd le a szükséges eseményadatokat. Ha a termékednek e-kereskedelmi adat kell a Brevóban, a Tajóval kösd össze a vásárlói, hozzájárulási, termék-, kosár- és rendelési eseményeket, mielőtt további életciklus-üzeneteket építesz. Ha inkább SMTP beállítás kell, nézd meg a [teljes SMTP útmutatót](https://tajo.io/hu/blog/smtp-complete-guide/) és az [ingyenes SMTP szerverekről szóló útmutatót](https://tajo.io/hu/blog/free-smtp-relay-guide/). ## Hol kap szerepet a Tajo A Tajo egy integrációépítő eszköz. Építsen integrációkat. Állítson rájuk ügynököket. Hagyja, hogy ők vigyék az ügyfélkapcsolatot. A Tajo korai hozzáférésben érhető el. [Kérj korai hozzáférést](https://tajo.io/hu/#early-access) ## Gyakran Ismételt Kérdések **Mi az e-mail API?** Az e-mail API olyan HTTP-felület, amellyel az alkalmazás kódból küldhet és kezelhet e-mailt. SMTP-kapcsolat nyitása helyett az alkalmazás strukturált kéréseket küld az e-mail platformnak, jellemzően JSON törzzsel, hitelesítési fejlécekkel, sablonokkal, webhookokkal és eseményriportokkal. **E-mail API-t vagy SMTP-t használjak?** E-mail API-t akkor használj, ha te felelsz az alkalmazás kódjáért, és strukturált válaszokra, sablonokra, metaadatokra, esemény-webhookokra, újrapróbálkozásra vagy nagy volumenű tranzakciós folyamatokra van szükséged. SMTP-t akkor használj, ha örökölt rendszert, WordPress bővítményt, szervert vagy olyan eszközt integrálsz, ami csak SMTP hitelesítő adatokat támogat. **Melyik e-mail API a legjobb?** A legjobb e-mail API a feladattól függ. A Brevo akkor erős választás, ha az e-mail összeér a CRM-mel, az SMS-sel, a WhatsApppal és a marketingautomatizálással. A SendGrid és a Mailgun a fejlesztők vezette küldő csapatoknak való. Az Amazon SES az AWS-re épülő, nagy volumenű infrastruktúrához illik. A Postmark azoknak jó, akik tranzakciós fókuszú terméket akarnak világos üzenetfolyamokkal. ## Kapcsolódó cikkek ### [Tranzakciós e-mail szolgáltatások összehasonlítása: API, SMTP, árazási modellek és illeszkedés (2026)](https://tajo.io/hu/blog/best-transactional-email-service/) 2026\. márc. 26. · 13 perc olvasás 9 szakasz ### [Tranzakciós e-mail szolgáltatás: Hogyan válasszuk ki a megfelelő szolgáltatót](https://tajo.io/hu/blog/transactional-email-service-guide/) 2026\. márc. 26. · 7 perc olvasás 8 szakasz ### [SMTP teljes útmutató: mi ez, hogyan működik, és a legjobb gyakorlatok](https://tajo.io/hu/blog/smtp-complete-guide/) 2026\. márc. 8. · 14 perc olvasás 11 szakasz