API üzerinden e-posta aktivasyonu, kaydın telefonla değil e-postayla doğrulandığı durumlarda gerekir: e-posta istemcileri, telefon doğrulaması istemeyen reklam hesapları, forumlar ve doğrulama kodunun ya da bağlantının yalnızca e-postayla geldiği hizmetler. E-posta aktivasyonu için kutu talep etme döngüsünün nasıl işlediğini, sık görülen yanıt kodlarının ne anlama geldiğini ve istek sınırına takılmadan durumun nasıl sorgulanacağını inceleyelim.
E-posta aktivasyonunun yaşam döngüsü: talepten koda
Döngü dört adımdan oluşur. Önce istemci belirli bir site için kutu talep eder: istek parametrelerinde kayıt yaptırmak istediğiniz hizmet belirtilir. Sistem boş bir adresi ayırır ve aktivasyon kimliğini döndürür; bu andan itibaren kutu talebe bağlanır ve aynı anda başka bir müşteriye verilmez. İkinci adım mektubu beklemektir: hedef site, verilen adrese doğrulama mektubunu gönderir ve bu, gönderenin hızına bağlı olarak birkaç saniyeden birkaç dakikaya kadar sürebilir. Üçüncü adım kodu almaktır: mektup teslim edilir edilmez API, ilgili sitedeki doğrulama biçimine göre mektuptaki kodu ya da bağlantıyı verir. Dördüncü adım aktivasyonu tamamlamaktır; kod uygunsa aktivasyon tamamlanır, kayıt başarısız olduysa ve kutunun süre dolmadan erkenden serbest bırakılması gerekiyorsa iptal edilir.
Kutu neden yalnızca belirtilen sitelerden gelen mektupları kabul eder
E-posta aktivasyonu siparişi verirken kutunun gelen postayı kabul etmesi gereken siteyi ya da site listesini belirtirsiniz. Bu teknik bir kısıtlama değil, bilinçli bir gönderen filtresidir: listenin dışındaki kaynaklardan gelen mektuplar işlenmez ve API üzerinden verilmez. Bunun iki amacı vardır. Birincisi, tek bir fiziksel kutu, müşteriler arasında mektupların karışma riski olmadan farklı hizmetlere ait talepleri aynı anda karşılayabilir. İkincisi, filtre, aksi halde gelen kutusu kuyruğunu dolduracak ve yazışmaların işlenmesini yavaşlatacak toplu postalardan ve oltalama mektuplarından korur. Kayıt yaptırdığınız site, sipariş sırasında belirttiğiniz listede yoksa mektup API çıktısına hiç düşmez; kod uzun süre gelmediğinde ilk kontrol etmeniz gereken şey budur.
Sık görülen yanıt kodları ve pratikte ne anlama geldikleri
«Boş kutu yok» kodu, belirli bir site için adres havuzunun geçici olarak tükendiği anlamına gelir: ya bir iki dakika bekleyip talebi yinelemek ya da hizmet izin veriyorsa aynı ailedeki komşu site için talep oluşturmak gerekir. «Mektup henüz gelmedi» kodu bir hata değil, normal bir ara durumdur: aktivasyon oluşturulmuştur, kutu gelen mektubu beklemektedir ve makul bir aralıkla yapılan tekrar sorgu er ya da geç hazır kodu döndürür. «Aktivasyonun süresi doldu» kodu, mektup ayrılan süre içinde gelmediğinde görünür: sınır, kutuların unutulmuş taleplerin altında sonsuza kadar boşta kalmaması için vardır ve süre dolduktan sonra adres ortak havuza döner. «İptal kabul edildi» kodu, aktivasyonu erkenden sizin kapattığınızı doğrular; bunun süre dolmasından temel farkı, inisiyatifin sistem zaman aşımından değil müşteriden gelmesidir. Havuz alışılmadık biçimde uzun süre boş kalıyorsa, istekleri elle tekrarlamak yerine destek talebi üzerinden destekle iletişime geçip ilgili site için yenileme beklenip beklenmediğini öğrenmek daha hızlıdır.
Gereksiz yük oluşturmadan durum nasıl sorgulanır
Entegrasyonu bozmanın yaygın yolu, aktivasyon durumunu duraksamadan, saniyede birkaç kez döngüyle sorgulamaktır. Bu, mektubun teslimini hızlandırmaz: hızı belirleyen şey, API'yi ne sıklıkla çağırdığınız değil, gönderen sitenin mektubu ne kadar çabuk oluşturup yolladığıdır. Makul aralık birkaç saniyede bir sorgulamaktır; durum uzun süre değişmiyorsa bekleme süresi kademeli olarak artırılabilir. Bu düzen istek sınırına sığar, aynı isteklerden oluşan bir kuyruk yaratmaz ve koda ulaşma hızı bakımından sık sorgulamadan farklı değildir; fark yalnızca harcanan istek sayısında ortaya çıkar. Aynı ilke kataloğun diğer API'lerinde de geçerlidir; örneğin API ile IP rotasyonu kurulumunda: sık sorgulama sonucu hızlandırmaz, yalnızca sınırı tüketir.
Otomasyonda e-posta aktivasyonu ve SMS aktivasyonu
Toplu kayıt senaryosunda e-posta ve SMS farklı işleri çözer ve genellikle birlikte kullanılır. SMS aktivasyonu telefon numarasına bağlıdır: doğrulama kodu, aktivasyon süresince erişilebilen belirli bir sanal hatta gelir, maliyet ise ülkeye ve hizmete göre değişir; güncel yönler SMS alma bölümünde toplanmıştır. E-posta aktivasyonu ise kiralama süresi boyunca bir ya da birkaç belirtilen siteden birden fazla mektup alabilen e-posta kutusuna bağlıdır; bu model, doğrulamanın gecikmeyle geldiği, kısa kodu girmek yerine bağlantıya tıklamayı gerektirdiği ya da hizmetin telefon hiç istemediği durumlarda daha yararlıdır. Benzer yapıdaki bir yaklaşım kataloğun diğer API'lerinde de kullanılır; örneğin API üzerinden proxy kanallarının verilmesi ve uzatılması döngüsünde: sipariş, kullanım, uzatma ya da kaynaktan vazgeçme, hepsi elle müdahale olmadan. Kayıt otomasyonunu tasarlarken her iki kanalı birlikte planlamak gerekir: birbirini tamamlarlar ve seçim, belirli bir sitenin tam olarak ne istediğine bağlıdır.
Sıkça Sorulan Sorular
Bir kutu aynı anda birden fazla site için kullanılabilir mi?
Evet, sipariş sırasında izin verilen gönderenler listesinde birden fazla site belirttiyseniz kutu, tek bir kiralama kapsamında her birinden mektup kabul eder; her hizmet için ayrı bir adres sipariş etmeniz gerekmez.
Kod geldi ama sitede kabul edilmediyse ne yapmalıyım?
Önce kodun sitenin kendi tarafında süresinin dolup dolmadığını kontrol edin; birçok hizmette kodun geçerlilik süresi API'den bağımsız olarak kısadır. Kod güncel olduğu halde yine de kabul edilmiyorsa, mektup büyük olasılıkla başka bir adresten tekrarlanmıştır ya da site standart dışı bir biçim kullanıyordur; kesilmiş bir parçaya değil, mektubun tamamına bakmak gerekir.
API'ye çok sık istek gönderildiği nasıl anlaşılır?
Belirtisi, beklenen aktivasyon durumu yerine istek sıklığı sınırı kodlarının dönmesidir. Bu düzenli olarak yaşanıyorsa sorgular arasındaki aralığı artırın; özellikle mektup bekleme aşamasında durum, gönderen sitenin mektubu oluşturmasından daha hızlı değişemez.
Yöntemlerin, kutu talebi parametrelerinin ve aktivasyonu tamamlamanın tam açıklaması teknik dokümantasyonda, API sayfasındadır.