E-posta API: Programatik E-posta Göndermenin Eksiksiz Rehberi (2026)

Bir e-posta API’si, uygulamanızın HTTP istekleri aracılığıyla e-posta göndermesini sağlar.

Kulağa basit geliyor, ancak bu karar ürün güvenilirliğini, teslim edilebilirliği, mühendislik iş akışını, analitiği, uyumluluğu, müşteri deneyimini ve destek operasyonlarını doğrudan etkiler.

Bu sayfanın eski sürümü doğru ana hatlara sahipti ama yeterince derin değildi. API’leri karşılaştırıyor, kısa bir Brevo örneği gösteriyor ve API ile SMTP’nin ne zaman kullanılacağını açıklıyordu. Bu güncelleme aynı yapıyı koruyor ve satıcı sayfası yakalamalarının yanı sıra Brevo, SendGrid, Mailgun, Amazon SES ve Postmark’ın güncel dokümantasyon ve fiyatlandırma sayfaları ile Tajo’nun kendi mesajlaşma API dokümanlarını kullanarak bu yapıyı eksiksiz, araştırmaya dayalı bir uygulama rehberine dönüştürüyor.

Kısa Yanıt

Uygulama tarafından tetiklenen e-postalara ihtiyacınız olduğunda bir e-posta API’si kullanın:

• Kayıt doğrulama.
• Parola sıfırlama.
• Sihirli bağlantı (magic link) ile giriş.
• Sipariş onayı.
• Kargo bildirimi.
• Fatura veya makbuz.
• Ürün daveti.
• Deneme sürümü alıştırma (onboarding) e-postaları.
• Kullanım uyarısı.
• Başarısız ödeme bildirimi.
• Yenileme hatırlatması.
• Ürün olaylarına dayalı yaşam döngüsü otomasyonu.

Gönderim yapan sistem yalnızca SMTP kimlik bilgilerini destekliyorsa ya da eski bir uygulama, eklenti, sunucu veya dahili araç için standartlaştırılmış bir posta aktarım katmanına ihtiyacınız varsa SMTP kullanın.

En iyi e-posta API’si seçimi teknoloji yığınınıza bağlıdır:

Yalnızca başlıktaki fiyata bakarak seçim yapmayın. E-posta API maliyeti; mühendislik zamanını, teslim edilebilirlik çalışmasını, veri modellemeyi, izlemeyi, desteği ve gelecekteki geçiş riskini de kapsar.

E-posta API’si ve SMTP Karşılaştırması

Hem API hem de SMTP e-posta gönderebilir. Fark, uygulamanızın mesajı gönderim platformuna nasıl teslim ettiğidir.

SMTP, uzun süredir kullanılan posta aktarım protokolüdür. Birçok araçla çalışır ve bir ürün ana bilgisayar, bağlantı noktası, kullanıcı adı ve parola ayarları beklediğinde hâlâ kullanışlıdır.

E-posta API’si ise bir HTTP arayüzüdür. Uygulamanız bir uç noktaya kimlik doğrulama bilgileri, alıcılar, içerik, şablon verileri, meta veriler ve bazen zamanlama ya da toplu gönderim ayrıntıları içeren bir istek gönderir.

Pratik kural şudur: uygulama kodu size aitse API ile başlayın. Yalnızca SMTP destekleyen bir üçüncü taraf aracı yapılandırıyorsanız SMTP kullanın.

E-posta API’si Nasıl Çalışır?

Temel bir gönderim akışı yedi adımdan oluşur:

1. Uygulamanız user_signed_up veya order_paid gibi bir olay oluşturur.
2. Uygulama bir mesaj türü seçer.
3. Uygulama alıcı, gönderen, şablon ve kişiselleştirme verilerini yükler.
4. Uygulama, e-posta sağlayıcısına kimliği doğrulanmış bir HTTP isteği gönderir.
5. Sağlayıcı isteği doğrular ve mesajı kuyruğa alır.
6. Sağlayıcı başarı, hata veya mesaj tanımlayıcıları içeren bir yanıt döndürür.
7. Webhook’lar teslimat, geri dönme, tıklama, şikâyet veya abonelikten çıkma olaylarını sisteminize geri bildirir.

API isteği yalnızca bir parçadır. Güvenilir bir uygulama aynı zamanda idempotans (tekrar güvenliği), yeniden denemeler, günlük kaydı, bastırma yönetimi, uyarılar ve veri yönetişimi gerektirir.

Hızlı Başlangıç: Brevo API ile E-posta Gönderme

Brevo’nun işlemsel e-posta API’si, /v3/smtp/email uç noktasına kimliği doğrulanmış bir istek kullanır. SDK ve alan adları tam olarak değişebilir, bu nedenle uygulama sırasında tek doğru kaynak olarak satıcının API referansını kullanın.

Örnek istek:

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

Üretim kodu API anahtarlarını sabit olarak içermemelidir. Gizli bilgileri bir gizli anahtar yöneticisinde veya ortam değişkeninde saklayın, düzenli olarak yenileyin, erişimi kısıtlayın ve asla ön yüz (frontend) kodunda açığa çıkarmayın.

Üretim Ortamında E-posta API Mimarisi

Üretim ortamındaki bir e-posta API entegrasyonu, her denetleyiciden veya rota işleyicisinden doğrudan gönderim yapmamalıdır.

Küçük bir mesaj katmanı kullanın:

1. Ürün olayı gerçekleşir.
2. Uygulama olayı bir kuyruğa, işe veya olay veri yoluna yazar.
3. E-posta servisi olayı bir şablonla eşler.
4. E-posta servisi alıcı iznini ve bastırma kurallarını doğrular.
5. E-posta servisi sağlayıcının API’sini çağırır.
6. E-posta servisi sağlayıcının mesaj kimliğini kaydeder.
7. Webhook’lar mesaj durumunu daha sonra günceller.

Bu yaklaşım ürün kodunu temiz tutar ve e-posta hatalarını izole etmeyi kolaylaştırır.

Önerilen dahili alanlar:

• 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.

Kritik mesajlar için idempotans anahtarları kullanın. Sağlayıcı ilk mesajı kabul ettikten sonra bir ağ isteği zaman aşımına uğradı diye yeniden deneme mekanizması üç ayrı parola sıfırlama e-postası göndermemelidir.

En İyi E-posta API’lerinin Karşılaştırması

Brevo

Brevo, işlemsel e-posta daha geniş bir müşteri iletişim sisteminin parçası olduğunda faydalıdır.

Şu durumlarda Brevo’yu seçin:

• İşlemsel e-postanın yanı sıra kampanyalara, CRM’e, otomasyona, SMS’e veya WhatsApp’a ihtiyacınız varsa.
• E-ticaret verileri yaşam döngüsü mesajlarını tetiklemeliyse.
• Pazarlama ve ürün mesajlaşmasının kişi profillerini paylaşması gerekiyorsa.
• Geliştirici olmayan ekip üyelerinin şablonlara ve raporlamaya erişmesi gerekiyorsa.
• Her kanal için ayrı ayrı nokta çözümler yerine tek bir platform istiyorsanız.

Dikkat edilmesi gerekenler:

• Pazarlama e-postası ile işlemsel e-posta yapılandırması arasındaki fark.
• Mühendislik ve pazarlama ekipleri arasında şablon sahipliği.
• Hız sınırları ve plan kısıtlamaları.
• Kişi verilerinin nasıl senkronize edildiği.
• Abonelikten çıkma ve bastırma kurallarının farklı mesaj kategorilerine nasıl uygulandığı.

Brevo’nun dokümantasyonu işlemsel gönderimi, toplu gönderimi, sandbox modunu, SMTP aktarımını, Webhook’ları, SDK’ları ve API referans sayfalarını kapsar. Uygulama ayrıntıları için bu dokümanları kullanın.

SendGrid

SendGrid, geniş dil ve platform desteğine sahip olgun bir geliştirici e-posta API’si isteyen ekipler için yaygın bir tercihtir.

Şu durumlarda SendGrid’i seçin:

• Geliştiriciler tanıdık bir e-posta API’si ve SDK ekosistemi istiyorsa.
• Aynı satıcıdan hem işlemsel hem de pazarlama e-postasına ihtiyacınız varsa.
• Mevcut bir Twilio altyapınız varsa.
• Olay Webhook’larına ve ayrıntılı gönderim kontrollerine ihtiyacınız varsa.

Dikkat edilmesi gerekenler:

• Seçilen plana hangi teslim edilebilirlik ve destek özelliklerinin dahil olduğu.
• Şablonların ortamlar arasında nasıl yönetildiği.
• Pazarlama e-postası ile işlemsel e-postanın aynı hesap yapısını paylaşıp paylaşmaması gerektiği.

Mailgun

Mailgun, geliştirici odaklı gönderim ve API öncelikli iş akışları etrafında tasarlanmıştır.

Şu durumlarda Mailgun’ı seçin:

• E-posta altyapısı mühendislik ekibine aitse.
• HTTP ile gönderim, SMTP yedeği, günlükler, gelen e-posta rotaları ve doğrulama araçlarına ihtiyacınız varsa.
• Teslim edilebilirlik operasyonları konusunda açık ve net bir sağlayıcı istiyorsanız.

Dikkat edilmesi gerekenler:

• Hangi doğrulama, analitik ve teslim edilebilirlik özelliklerinin dahil olduğu.
• Veri saklama ve günlük erişimi.
• Geçiş ve ısınma (warmup) sürecinde destek beklentileri.

Amazon SES

Amazon SES altyapı odaklıdır.

Şu durumlarda Amazon SES’i seçin:

• Uygulamanız zaten büyük ölçüde AWS üzerinde çalışıyorsa.
• Kurulumun daha büyük bir kısmını üstlenecek mühendislik kaynaklarına sahipseniz.
• Yüksek hacimli, kullandıkça öde gönderimine ihtiyacınız varsa.
• IAM, CloudWatch, SNS, Lambda veya diğer AWS hizmetleriyle sıkı entegrasyon istiyorsanız.

Dikkat edilmesi gerekenler:

• Sandbox kısıtlamasının kaldırılması ve üretim erişimi.
• Alan adı kimliği kurulumu.
• Geri dönme ve şikâyet yönetimi.
• Özel IP kararları.
• İzleme ve uyarı mekanizmaları.
• Diğer sağlayıcıların ürün arayüzünde sunduğu özellikleri kendiniz geliştirmenin mühendislik maliyeti.

SES ölçekte mükemmel olabilir, ancak her ekip için en az çaba gerektiren seçenek değildir.

Postmark

Postmark, işlemsel e-postaya odaklanmıştır.

Şu durumlarda Postmark’ı seçin:

• İşlemsel güvenilirlik ve netlik, hepsi bir arada pazarlama genişliğinden daha önemliyse.
• E-posta türlerini birbirinden ayıran mesaj akışları istiyorsanız.
• Sade bir üründe şablonlara, gelen e-postaya ve teslimat olaylarına ihtiyacınız varsa.

Dikkat edilmesi gerekenler:

• Hacminize göre fiyatlandırma kademeleri.
• Olay ve mesaj saklama süresinin ne kadar olması gerektiği.
• Toplu pazarlama gönderimlerinin ayrı bir akışa veya platforma ait olup olmadığı.

Tajo

Tajo, e-posta gönderimi e-ticaret, müşteri olayları ve Brevo’ya bağlı otomasyonla ilişkili olduğunda devreye girer.

Şu durumlarda Tajo’yu kullanın:

• Ürün ve e-ticaret olaylarının Brevo’ya akması gerekiyorsa.
• Shopify veya diğer ticaret verileri terk edilmiş sepet, sipariş veya yaşam döngüsü mesajlaşmasını tetiklemeliyse.
• Müşteri, sipariş, ürün ve olay verileri için tek bir entegrasyon katmanı istiyorsanız.
• Daha geniş müşteri veri modelinize bağlı, dokümante edilmiş bir işlemsel mesajlaşma yoluna ihtiyacınız varsa.

Tajo, bir sağlayıcının kendi API referansının yerini almamalıdır. Tajo’nun görevi, doğru müşteri ve olay verilerini mesajlaşma sistemine ulaştırmak için gereken entegrasyon işini azaltmaktır.

E-posta API’si Ne Zaman Kullanılmalı?

İşlemsel E-postalar

İşlemsel e-postalar, bir kullanıcı eylemi veya sistem olayı tarafından tetiklenir.

Örnekler:

• Hesap doğrulama.
• Sihirli bağlantı ile giriş.
• Parola sıfırlama.
• İki faktörlü kimlik doğrulama.
• Ürün daveti.
• Sipariş onayı.
• Ödeme makbuzu.
• Kargo onayı.
• Teslimat güncellemesi.
• İade bildirimi.
• Abonelik yenileme.
• Başarısız ödeme uyarısı.
• Güvenlik bildirimi.

İşlemsel e-postada güvenilirlik beklentisi yüksektir. Bir giriş bağlantısı, sipariş makbuzu veya parola sıfırlama e-postası gelmediğinde kullanıcılar bunu anında fark eder.

Ayrıca bakınız: sipariş onayı e-postaları ve işlemsel e-posta örnekleri.

Ürün Yaşam Döngüsü E-postaları

Yaşam döngüsü e-postaları, işlemsel ve pazarlama e-postaları arasında yer alır.

Örnekler:

• Deneme sürümü alıştırma süreci.
• Özellik etkinleştirme.
• Kullanım kilometre taşı.
• Yükseltme önerisi.
• Etkin olmayan hesap hatırlatması.
• Müşteri başarısı kontrol mesajı.
• Yenileme dizisi.
• Geri kazanma mesajı.

Bu e-postalar, genel bir takvim yerine ürün verileriyle tetiklendiğinde en iyi sonucu verir.

E-ticaret E-postaları

E-ticaret ekipleri genellikle hem işlemsel hem de pazarlama tarafından tetiklenen e-postalara ihtiyaç duyar:

• Hoş geldin teklifi.
• Terk edilmiş sepet.
• Terk edilmiş gezinme.
• Yeniden stokta.
• Fiyat düşüşü.
• Ürün önerisi.
• Yeniden sipariş hatırlatması.
• Sadakat güncellemesi.
• Değerlendirme talebi.
• VIP erken erişim.

Shopify ve Brevo kullanan ekipler için Tajo; sipariş, müşteri, izin, ürün ve sepet verilerini birbirine bağlayarak bu mesajların gerçek alışveriş davranışına göre tetiklenmesine yardımcı olabilir.

API ile Pazarlama E-postaları

Pazarlama e-postasını yalnızca toplu bir bülten işi olarak görmeyin.

API ile tetiklenen pazarlama şunları destekleyebilir:

• Olay tabanlı segmentasyon.
• Kişiselleştirilmiş kampanyalar.
• Tetiklenen damla (drip) dizileri.
• Ürün odaklı alıştırma süreci.
• Hesap bazlı yaşam döngüsü yolculukları.
• Müşteri davranışına bağlı otomatik e-posta.

Uyumluluk çıtası burada da geçerlidir. Pazarlama mesajları uygun izin, abonelikten çıkma yönetimi ve bastırma kuralları gerektirir.

Aranması Gereken Temel API Özellikleri

Kimlik Doğrulama ve Anahtar Yönetimi

Ciddi bir e-posta API’si güvenli API anahtarlarını ve net kimlik doğrulama dokümanlarını desteklemelidir.

Operasyonel gereksinimler:

• Anahtarları ortama göre ayırın.
• Üretim anahtarlarına erişimi kısıtlayın.
• Anahtarları düzenli olarak yenileyin.
• Anahtarları kodun dışında saklayın.
• Anahtar değerini kaydetmeden anahtar kullanımını günlüğe alın.
• Başarısız istek dökümlerinden anahtarları kaldırın.

Şablonlar

Şablonlar işlemsel e-postayı tutarlı tutar.

Şunlara bakın:

• Sürüm yönetimi.
• Test gönderimleri.
• Değişkenler.
• Varsayılan (fallback) değerler.
• Yerelleştirme.
• Önizleme oluşturma.
• Onay iş akışları.
• Ayrı hazırlık (staging) ve üretim şablonları.

Şablonlar yalnızca tasarım varlıkları değildir. Ürün sözleşmesinin bir parçasıdır. Bir parola sıfırlama şablonu, sipariş onayı şablonu veya fatura şablonu, uygulama arayüzüyle aynı ciddiyetle gözden geçirilmelidir.

Webhook’lar

Webhook’lar gönderimi bir geri bildirim döngüsüne dönüştürür.

Şunları izleyin:

• İşlendi.
• Ertelendi.
• Teslim edildi.
• Açıldı (temkinli yaklaşın).
• Tıklandı (temkinli yaklaşın).
• Geri döndü.
• Düşürüldü.
• Şikâyet edildi.
• Abonelikten çıkıldı.

Webhook olaylarının dahili kullanıcılar ve olaylarla eşleştirilebilmesi için sağlayıcının mesaj kimliklerini saklayın.

Bastırma Yönetimi

Bastırma (hariç tutma) yönetimi teslim edilebilirliği ve uyumluluğu korur.

Sistem şunları yönetebilmelidir:

• Sert geri dönmeler (hard bounce).
• Şikâyetler.
• Abonelikten çıkmalar.
• Manuel engellemeler.
• Politikanız hariç tutuyorsa rol tabanlı adresler.
• Geçersiz kişiler.
• Hesap silme veya gizlilik talepleri.

Ürün kodu “e-posta gönder” işlemini yalnızca bir arka plan görevi olarak gördüğü için kalıcı olarak başarısız olan bir adresi sürekli yeniden denemeyin.

Hız Sınırları ve İşlem Kapasitesi

Sağlayıcının şunları nasıl yönettiğini kontrol edin:

• API istek sınırları.
• Mesaj işlem kapasitesi.
• Toplu gönderim uç noktaları.
• Ani yük (burst) sınırları.
• Günlük veya aylık plan sınırları.
• Yeni hesap ısınma süreci.
• Özel IP ısınma süreci.

Yoğun dönemleri planlayın. Bir ürün lansmanı, parola sıfırlama olayı, Black Friday indirimi veya güvenlik bildirimi, günlük ortalamanın çok üzerinde gönderim hacmi oluşturabilir.

Analitik ve Dışa Aktarımlar

Asgari raporlama:

• Gönderildi.
• Teslim edildi.
• Geri döndü.
• Ertelendi.
• Şikâyetler.
• Abonelikten çıkmalar.
• Şablon performansı.
• Sağlayıcı yanıt hataları.
• İlgili olduğunda gelir veya dönüşüm olayları.

Açılma ve tıklama verilerine temkinli yaklaşın. Gizlilik korumaları, görsel engelleme ve bot etkinliği etkileşim metriklerini çarpıtabilir. İşlemsel e-postada teslimat ve başarılı kullanıcı eylemi çoğu zaman açılma oranından daha önemlidir.

Gelen E-posta Ayrıştırma

Kullanıcılar yanıt verdiğinde veya ürüne içerik gönderdiğinde gelen e-posta önem kazanır.

Kullanım senaryoları:

• Destek yanıtları.
• E-postadan destek talebine dönüştürme.
• Yanıtla yorum yapma.
• Onay iş akışları.
• İletilen makbuzlar.
• Gelen potansiyel müşteri yakalama.

Gelen e-posta ayrıştırma yol haritanızın parçasıysa, net dokümanlara, yönlendirmeye, güvenlik kontrollerine ve ek dosya yönetimine sahip bir sağlayıcı seçin.

E-posta API’si ile Teslim Edilebilirlik

Bir API teslim edilebilirlik sorununu kendiliğinden çözmez.

Yine de şunlara ihtiyacınız var:

• SPF.
• DKIM.
• DMARC.
• Doğrulanmış gönderim alan adları.
• Tutarlı gönderen kimliği.
• Temiz listeler.
• Geri dönme yönetimi.
• Şikâyet yönetimi.
• Pazarlama mesajları için net abonelikten çıkma seçeneği.
• İlgili içerik.
• Makul gönderim sıklığı.
• İzleme.

Yeni alan adları veya IP’ler için kademeli olarak ısınma yapın. Düşük riskli, yüksek etkileşimli e-postalarla başlayın ve itibar istikrar kazandıkça hacmi artırın.

Mümkün olduğunda mesaj türlerini ayırın:

• Kimlik doğrulama ve güvenlik.
• Makbuzlar ve sipariş güncellemeleri.
• Ürün yaşam döngüsü.
• Pazarlama.
• Toplu promosyonlar.

Agresif bir promosyon kampanyasının parola sıfırlama veya makbuz teslimatına zarar vermesine izin vermeyin.

Hata Yönetimi ve Yeniden Denemeler

E-posta API hataları sınıflandırılmalıdır.

Yeniden deneyin:

• Zaman aşımı.
• Geçici sağlayıcı hatası.
• Bekleme süresinden sonra hız sınırı.
• Ağ hatası.
• Geçici kuyruk sorunu.

Sonsuza kadar yeniden denemeyin:

• Geçersiz alıcı adresi.
• Yetkisiz API anahtarı.
• Geçersiz şablon kimliği.
• Eksik zorunlu alan.
• Bastırılmış alıcı.
• Politika veya uyumluluk engeli.

Üstel geri çekilme (exponential backoff) kullanın ve yeniden denemelerden sonra hâlâ başarısız olan mesajlar için bir ölü mektup kuyruğu (dead-letter queue) oluşturun.

Her kritik e-postanın operasyonel bir yolu olmalıdır:

• Destek ekibi yeniden gönderebiliyor mu?
• Kullanıcı tekrar talep edebiliyor mu?
• Mühendislik olayı izleyebiliyor mu?
• Sağlayıcı yanıtını görebiliyor musunuz?
• Sağlayıcı tarafından kabul edilip edilmediğini kanıtlayabiliyor musunuz?

E-posta API Uygulama Kontrol Listesi

Yayına almadan önce bu kontrol listesini kullanın.

1. Mesaj türlerini ve sahiplik alanlarını belirleyin.
2. API sağlayıcısını ve yedek yaklaşımı seçin.
3. Gönderen alan adlarını doğrulayın.
4. SPF, DKIM ve DMARC’ı yapılandırın.
5. Hazırlık ve üretim API anahtarları oluşturun.
6. Gizli bilgileri güvenli şekilde saklayın.
7. Bir mesaj servisi veya adaptör oluşturun.
8. İdempotans anahtarları ekleyin.
9. Yapılandırılmış günlükler ekleyin.
10. Yeniden deneme ve ölü mektup davranışını oluşturun.
11. Şablonları oluşturun.
12. Kişiselleştirmeyi ve varsayılan değerleri test edin.
13. Webhook’ları yapılandırın.
14. Sağlayıcı mesaj kimliklerini saklayın.
15. Geri dönmeleri, şikâyetleri ve abonelikten çıkmaları yönetin.
16. Yeniden gönderim ve durum sorgulama için destek araçları oluşturun.
17. Hata oranlarını ve teslimat oranlarını izleyin.
18. Hız sınırlarını ve olay müdahale planlarını dokümante edin.

Sağlayıcı Seçim Puan Kartı

Her satıcıyı 1’den 5’e kadar puanlayın:

Birçok ekip için doğru cevap “en ucuz e-posta API’si” değildir. Doğru cevap, müşterilerin bağımlı olduğu e-posta türleri için operasyonel riski azaltan sağlayıcıdır.

Yaygın Hatalar

Şunlardan kaçının:

• Dağınık uygulama kodundan doğrudan gönderim yapmak.
• API anahtarlarını veya özel veri içeren tam yükleri günlüğe kaydetmek.
• Her hatayı geçiciymiş gibi yeniden denemek.
• Sağlayıcı mesaj kimliklerini yok saymak.
• Destek ekibi “e-posta ulaştı mı?” diye sorana kadar Webhook’ları unutmak.
• Parola sıfırlamalarını ve toplu pazarlamayı aynı itibar yolunda karıştırmak.
• Her yerel ayar için tek bir şablon kullanmak.
• Şablon değişkenleri için varsayılan değerleri atlamak.
• Açılmaları teslimatın veya müşteri başarısının kanıtı olarak görmek.
• Bilinçli bir politika olmadan pazarlama abonelikten çıkma mantığının zorunlu hesap güvenliği mesajlarını bastırmasına izin vermek.
• Sağlayıcıları yalnızca ücretsiz kademeye göre karşılaştırmak.
• Isınma süreci olmadan yüksek hacimle yayına başlamak.

Başlarken

Yeni bir uygulama için en kısa güvenli yolu izleyin:

1. Parola sıfırlama veya sipariş onayı gibi tek bir işlemsel mesajla başlayın.
2. Ürün kodunu tek bir satıcıya bağlamak yerine bir sağlayıcı adaptörü oluşturun.
3. Alan adı kimlik doğrulamasını ekleyin.
4. Webhook ile durum takibi ekleyin.
5. Destek ekibi için görünürlük ekleyin.
6. Şablonlar ve yerelleştirme ekleyin.
7. Yaşam döngüsü ve e-ticaret otomasyonlarına genişleyin.

Ekibiniz pazarlama ve CRM için zaten Brevo kullanıyorsa Brevo’nun işlemsel API’siyle başlayın ve ihtiyacınız olan olay verilerini eşleyin. Ürününüzün e-ticaret verilerini Brevo’ya aktarması gerekiyorsa daha fazla yaşam döngüsü mesajlaşması kurmadan önce müşteri, izin, ürün, sepet ve sipariş olaylarını bağlamak için Tajo’yu kullanın.

Bunun yerine SMTP kurulumu için SMTP eksiksiz rehberine ve ücretsiz SMTP sunucusu rehberine bakın.

İlgili Rehberler

• İşlemsel e-posta servisi rehberi
• İşlemsel e-posta örnekleri
• SMTP eksiksiz rehberi
• SPF, DKIM ve DMARC
• E-posta otomasyonu rehberi
• Brevo Shopify entegrasyonu