E-posta Denetleyici API: Tekli, Çoklu ve Toplu İstekler Arasında Seçim Yapmak

Her iş için doğru e-posta denetleyici API isteğinin nasıl seçileceği ve teslim edilebilir, teslim edilemez ve belirlenemedi sonuçlarının koda nasıl aktarılacağı.

Bir e-posta denetleyici API, kimin beklediğine ve kaç adet adresiniz olduğuna bağlı olarak üç farklı biçimde çağrılmalıdır. Bir kişi tek bir adres için bekliyorsa tekli denetimi (POST /api/v1/check), küçük bir grup aynı anda geliyorsa senkron çoklu adres denetimini (POST /api/v1/batch-check, 1–100 adres, giriş sırasına göre sonuçlar) ve adresler zaten bir dosyada bulunuyorsa asenkron toplu görevi (POST /api/v1/bulk-tasks, ardından durum sorgulama) kullanın. Biçimi ne olursa olsun, kodunuzu evet/hayır bayrağı yerine üç sonuç etrafında tasarlayın: teslim edilebilir, teslim edilemez ve belirlenemedi; hatalı biçimlendirilmiş girdileri ise çağrıdan önce ele alın. Tamamlanan her sonuç, yalnızca denetim anındaki adresi tanımlar.

Bir e-posta denetleyici API neleri yanıtlar ve neleri size bırakır?

Bu konuyla ilgili sıralanan çoğu sayfa özellikleri listeler ve orada durur. Entegrasyon sorusu daha dardır: Bir çağrı aslında neye karar verir ve uygulamanızın sorumluluğunda ne kalır?

EmailCheckPro'nun E-posta Teslim Edilebilirlik Kontrolü, teslim edilebilir (adres denetim anında posta alabiliyordu) veya teslim edilemez şeklinde tamamlanmış bir sonuç döndürür. E-posta Profil Fotoğrafı Kontrolü ise bir genel profil fotoğrafı sinyali ekler, ancak bu yalnızca Gmail, Yandex ve Mail.ru adresleri için geçerlidir.

Uygulamanızın sorumluluğunda üç iş kalır:

• Biçim taraması. Tam bir adres; bir yerel bölüm, bir @ işareti ve bir alan adından oluşur. Hatalı biçimlendirilmiş girdi bir form hatasıdır, teslim edilemez kararı değildir; bu yüzden bir çağrı harcamadan önce bunu yakalayın.
• Bir onay bağlantısı veya kendi onay kayıtlarınız bunu kapsar.
• Zamanlama. Bir sonuç, denetim anına aittir. Sonucun yanına tarihi kaydedin, böylece sonraki işler verinin ne kadar eski olduğunu bilir.

Bu sınırları yalnızca dokümantasyonda değil, kodun içinde de tutmak, aşağıda açıklanan en yaygın entegrasyon hatalarını önler.

E-posta denetleyici API istek biçimini seçme

Üç istek biçimi birbirinin yerine kullanılamaz ve yanlış olanı seçmek, yavaş formların veya kırılgan içe aktarma işlerinin yaygın nedenidir.

Karar vermek için hızlı bir yol:

1. Ekranda bekleyen biri var mı? Sadece yazdıkları adres için tekli uç noktayı kullanın.
2. Adresler birlikte mi geliyor ve 100 adedi geçmiyor mu? Bir çoklu istek gönderin. Bu hala senkrondur: küçük bir toplu görev değil, daha büyük bir tekli çağrıdır.
3. Kaynak zaten bir dosya mı veya birkaç yüz satırdan çok daha mı fazla? Bir toplu görev gönderin ve bir arka plan çalışanının sonucu toplamasını bekleyin. Ürün bazlı görev limitleri geçerlidir ve API dokümantasyonunda listelenmiştir.
4. İşin profil fotoğraflarına ihtiyacı var mı? Listeyi önce desteklenen Gmail, Yandex ve Mail.ru alan adlarına göre filtreleyin. Desteklenmeyen bir alan adı gerçek zamanlı ücretlendirmeden önce reddedilir ve bir profil fotoğrafı toplu dosyasında hazırlığın başarısız olmasına neden olur, bu durumda rezervasyon iade edilir.

Dosyada olmayan birkaç yüz adres için, birkaç çoklu istek veya 500 adrese kadar işleyebilen kontrol panelinin gerçek zamanlı denetimi makuldür.

Sonuçları uygulama mantığına eşleme

Sonuçları bir boole değerine indirgemek, çoğu entegrasyonun yanlış yaptığı yerdir. Küçük bir durum türü, anlamı korur:

Dokümantasyondan üç kural çıkar:

• Tek bir gerçek zamanlı denetimde, belirlenemedi durumundaki bir adres sonuç yerine bir iş kodu döndürür ve ücretlendirilmez. Bu dalı, sıkı bir döngüde tekrar denenecek bir hata olarak değil, kendi durumu olarak ele alın.
• Çoklu yanıtta, her öğe tamamlanmış bir sonucun var olup olmadığını belirtir. Sadece tamamlanmış sonucu olanlar teslim edilebilir veya teslim edilemez taşır; geri kalanı belirlenemedi veya tamamlanmadı dalına aittir.
• Geçersiz, başarısız ve belirlenemedi denetimleri ücretlendirilmez, bu nedenle onları daha sonra tekrar denemek zamandan başka bir şeye mal olmaz. Tekrar denemeyi hemen tekrarlamak yerine planlayın.

Sürprizler olmadan asenkron toplu görevleri çalıştırma

Bir toplu görev küçük bir durum makinesidir ve bir web isteğinden ziyade bir arka plan çalışanına aittir.

1. Dosyayı hazırlayın. Her satırda bir tam e-posta adresi olacak şekilde TXT veya CSV yazın. Geçersiz ve yinelenen satırlar hazırlık sırasında kaldırılır, ancak bariz çöpleri önceden temizlemek kendi sayılarınızı mutabık kılmayı kolaylaştırır.
2. Gönderin ve kaydedin. POST /api/v1/bulk-tasks tarafından döndürülen görev referansını, kaynak dosya adı, kullanılan ürün ve gönderim zamanı ile birlikte veritabanınıza kaydedin. Çöken bir çalışan, yeniden göndermek yerine kaldığı yerden devam edebilir.
3. Sabırla sorgulayın. GET /api/v1/bulk-tasks/{id} sorgusunu 30 saniyeden daha sık yapmayın. Bir kez kontrol edip uyuyan planlanmış bir iş, bağlantıyı açık tutan bir döngüden daha uygundur.
4. Hemen indirin. Başarılı bir görev, 12 saat geçerli olan bir indirme bağlantısında bir CSV sağlar. Bağlantının süresi dolarsa, dosyayı ikinci kez yüklemek yerine aynı görevi yeni bir bağlantı için tekrar sorgulayın.
5. Adrese göre birleştirin. Hazırlık satırları düşürebileceğinden, sonuç CSV'sini kayıtlarınızla e-posta adresine göre birleştirin, asla satır numarasına göre değil.

Teslim edilebilirlik CSV'si, her adresi sonucuyla eşleştirir. Profil fotoğrafı CSV'si ayrıca bir genel profil fotoğrafı bulunup bulunmadığını belirtir ve bir profil fotoğrafı bağlantısı verir; bu bağlantı, profil fotoğrafı mevcut olduğunda bile boş olabilir, bu yüzden boş bir bağlantıyı normal bir değer olarak ele alın.

Entegrasyonu günlük olarak yönetme

İstek biçimleri ve durumlar doğru olduğunda, birkaç alışkanlık entegrasyonu sessiz tutar:

• Yalnızca sunucu tarafı anahtarları. API anahtarı, web denetimleri, REST çağrıları, toplu görevler ve MCP erişimi tarafından paylaşılan hesap bakiyesini harcar. Onu asla tarayıcı veya mobil kodda göndermeyin.
• Değişim noktasında denetleyin. Bir adres oluşturulduğunda veya düzenlendiğinde denetleyin, ardından her sayfa görüntülemesinde çağırmak yerine saklanan sonucu kendi yeniden denetim pencereniz içinde yeniden kullanın.
• Formda açık, hatta kapalı başarısızlık. Kayıt sırasında bir denetim yavaş veya sonuçsuzsa, kişinin bayraklı bir adresle devam etmesine izin verin. Gönderim hattında, bayraklı satırları tamamlanmış bir sonuç alana kadar bekletin.
• Kendi uç noktanızı koruyun. Uygulamanız bir "bu adresi denetle" rotası sunuyorsa, hız sınırlaması uygulayın ve tutarlı mesajlar döndürün. OWASP e-posta doğrulama rehberi, formların bir hesabın var olup olmadığını açığa çıkarmasına izin vermemeye karşı uyarır.
• Yapay zeka istemcilerine MCP uç noktasını verin. https://emailcheckpro.com/mcp, tekli denetimleri, çağrı başına 100 adrese kadar çoklu denetimleri, ürün listelemeyi ve bakiye sorgularını destekler. Dosya tabanlı toplu işler web iş akışında veya REST API'de kalır.

Güncel istek limitleri ve kullanım detayları EmailCheckPro API dokümantasyonunda yayınlanmıştır; varsayımları kodlamak yerine oradan okuyun.

API'nin beklentileriyle eşleşen bir biçim denetimi

En ucuz çağrı, hatalı biçimlendirilmiş girdiler için hiç yapmadığınız çağrıdır. İki referans, mantıklı bir tarama seçmenize yardımcı olur:

• WHATWG HTML standardı, tarayıcıların type="email" alanları için kullandığı deseni tanımlar. Pratik kalmak için tam posta standartlarından kasıtlı olarak ayrılır, bu da onu makul bir sunucu tarafı temeli yapar.
• RFC 5321, posta iletiminde kullanılan adres biçimlerini açıklar. Bunu, tırnak içindeki yerel bölümler gibi uç durumlar için bir biçim referansı olarak ele alın, herhangi bir denetim hizmetinin nasıl çalıştığının bir açıklaması olarak değil.

Uygulamada: boşlukları kırpın, belgelerden kopyalanan sondaki noktalama işaretlerini kaldırın, alan adını küçük harfe çevirin, yerel bölümü girildiği gibi tutun ve yalnızca yerel bölümü, @ işareti veya alan adı açıkça eksik olan girdileri reddedin. Artı işaretlerini veya uzun üst düzey alan adlarını reddeden aşırı katı desenler gerçek kullanıcıları geri çevirir ve bunlardan kaçınılmalıdır.

SSS

Ekipler çoklu adres çağrılarından toplu göreve ne zaman geçmelidir?

Adresler zaten bir dosyada yaşıyorsa veya bir işin bir listeyi işlemek için birçok ardışık çoklu çağrıya ihtiyacı varsa geçiş yapın. Çoklu istekler, birlikte gelen ve aynı yanıtta cevaplara ihtiyaç duyan 100 adede kadar grup için uygundur. Toplu görevler, sonuç daha sonra tek bir CSV olarak geldiği ve çalışan sadece 30 saniyede bir veya daha az sıklıkla durumu sorgulaması gerektiği için bekleyebilen hazırlanmış dışa aktarımlar için uygundur.

Bir uygulama e-posta denetleyici API sonuçlarını nasıl saklamalıdır?

Adresi girildiği gibi, kullanılan ürünü, sonucu düz kelimelerle, denetim tarihini ve adresin kaynağını saklayın. Bu kayıt, desteğin bir kararı açıklamasına, yeniden denetim işlerinin en eski sonuçları önce seçmesine ve belirlenemedi veya tamamlanmadı satırlarını teslim edilemez olanlardan ayrı tutmasına olanak tanır. Ham yanıt yüklerini tek kayıt olarak saklamaktan kaçının, çünkü diğer sistemler API'nin biçimine bağımlı hale gelir.

Teslim edilebilir bir sonuç, bir onay e-postasının yerini alabilir mi?

Hayır. Teslim edilebilir bir sonuç, adresin denetim anında posta alıp alamayacağını bildirir ve denetimin kendisi hiçbir şey göndermez. Bir onay bağlantısı farklı bir soruyu yanıtlar: adresi giren kişinin onu kontrol edip etmediği ve mesaj almayı kabul edip etmediği. Birçok kayıt akışı, göndermeden önce ölü adresleri yakalamak için denetimi kullanır, ardından onay ve sahiplik için onaya güvenir.

Tamamlanmayan denetimleri tekrar denemenin en güvenli yolu nedir?

Başarısız olan istekte tekrar denemek yerine, onları gecikmeli bir kuyruğa koyun. Belirlenemedi, başarısız ve geçersiz denetimleri ücretlendirilmez, ancak anında yeniden denemeler sonucu nadiren değiştirir ve kendi hizmetinizi yavaşlatabilir. Deneme sınırı ve her denemenin tarihinin not edildiği planlanmış bir yeniden deneme, kaydı dürüst tutar ve inceleyenlerin hangi adreslerin hala tamamlanmış bir sonucu olmadığını görmesini sağlar.

Daha Fazla Bilgi

İş akışınızdaki bir sonraki adıma uyan ürün bilgisini seçin.

• Ürün dokümantasyonunu görüntüle →
• Ekiple konuş →