Mesajlaşma API'si Nasıl Seçilir: CTO'lar için Kontrol Listesi

Bu kontrol listesi; SMS, WhatsApp, RCS ve diğer kanallar için bir mesajlaşma API'si seçen CTO'lar, mühendislik liderleri ve mimarlar içindir. Belirsiz bir tedarikçi karşılaştırmasını, belirli sorulara, bir öğleden sonra çalıştırabileceğiniz testlere ve finans ile güvenlik ekiplerine savunabileceğiniz bir puanlama tablosuna dönüştürür.

Zaten bir sağlayıcı seçtiyseniz ve entegrasyonu kurmanız gerekiyorsa bunun yerine mesajlaşma API entegrasyon rehberimizi okuyun. Bu makale, ondan önceki karar hakkındadır.

Bir CTO bir mesajlaşma API'sinde neleri değerlendirmelidir?

Üretim sonuçlarını etkileyenleri değerlendirin: mesajların ulaşıp ulaşmadığı, ne olduğunu görüp göremediğiniz, entegrasyonun hatalara dayanıp dayanmadığı ve uyumlu kalıp kalmadığı. Özellik listeleri sağlayıcılar arasında benzerdir; bu nitelikler ise değildir.

API ihtiyaç duyduğunuz kanalları kapsıyor mu?

Kanallar arasında tek bir temel URL, tek bir kimlik doğrulama şeması ve tek bir iletim durumu modeli arayın. Kanal başına ayrı entegrasyonlar, bakımını yaptığınız kodu ve bir durumun kaybolabileceği yerleri çoğaltır.

• Yalnızca bugünün değil, önümüzdeki iki yılın kanallarını listeleyin. SMS OTP ile başlayan ekipler çoğu zaman WhatsApp şablonlarını, sonra RCS'i, sonra e-postayı veya push'u ekler.
• Yalnızca logoyu değil, kanal derinliğini kontrol edin. WhatsApp için şablonları yönetebilir, etkileşimli mesajlar gönderebilir ve onayı API üzerinden takip edebilir misiniz? SMS için iki yönlü mesajlaşma, Unicode ve numara sorgulama mevcut mu?
• Yedeklemeyi kontrol edin. Bir WhatsApp mesajı iletilmezse platform RCS'e veya SMS'e yedekleyebilir mi ve sıra kullanım senaryosu başına yapılandırılabilir mi? WhatsApp, SMS ve RCS karşılaştırmamız her kanalın ne zaman uygun olduğunu açıklar.

Rota kalitesini nasıl değerlendirirsiniz?

Sağlayıcıya, en önemli pazarlarınızdaki her operatöre nasıl ulaştığını sorun, ardından kendiniz doğrulayın. Rota kalitesi, mesajın ulaşıp ulaşmadığını, SMS başlığınızın korunup korunmadığını ve iletim raporunun gerçekte olanı yansıtıp yansıtmadığını belirler.

Doğrudan rota, sağlayıcının uygulamadan kişiye (A2P) trafiği kapsayan bir sözleşme uyarınca operatöre veya yetkili bir iş ortağına bağlanması demektir. Gri rota ise A2P trafiğini, tüketici SIM bağlantıları gibi bu amaçla tasarlanmamış yollardan iter. Gri rotalar fiyat listesinde daha ucuz görünebilir, ancak gerçek riskler taşır:

• SMS başlığı rastgele bir numarayla değiştirilir; bu da güveni ve OTP otomatik doldurma alışkanlıklarını bozar;
• operatörler trafiği tespit edip bazen kampanyanın ortasında engeller;
• iletim raporları şebeke tarafından değil rota tarafından üretilebilir; bu yüzden "iletildi" gerçekten iletildi anlamına gelmeyebilir.

Sorulacak sorular:

1. Hedef ülkelerimizden ve operatörlerimizden hangilerine doğrudan ulaşıyorsunuz?
2. Her ülkede SMS başlığı kaydını nasıl yönetiyorsunuz?
3. İletim raporlarınız nereden geliyor ve operatörün hata kodunu iletiyor musunuz?
4. Bir rota bozulduğunda trafiğimize ne oluyor? Yeniden yönlendirme otomatik mi ve bize haber veriyor musunuz?

Ardından test edin: her büyük operatördeki gerçek cihazlara gönderin, görüntülenen SMS başlığını kontrol edin ve raporları telefonların gösterdiğiyle karşılaştırın. Kurumsal SMS'in operatörlere nasıl ulaştığına dair arka plan için A2P SMS nedir yazısına bakın.

İletim raporları ve webhook'lar nasıl ele alınır?

Sağlayıcı, iletim durumlarını HTTPS uç noktanıza kanallar arasında tek bir normalleştirilmiş biçimde iletmeli ve kaçırdığınız olayları kurtarmanız için bir yol sunmalıdır. Her mesajı yoklamak sürdürülebilir bir tasarım değildir.

İyisi nasıl görünür:

• Belgelenmiş bir durum listesi. Örneğin SUBMITTED, SENT, DELIVERED, READ, FAILED ve REJECTED; hangilerinin nihai olduğu belirtilmiş. İletim durumları rehberimiz her birinin pratikte ne anlama geldiğini açıklar.
• Başarısızlık nedenleri. FAILED veya REJECTED durumu, varsa operatör veya kanal nedenini taşımalıdır.
• Kurtarma. Uç noktanız kapalıysa bir tarih aralığı için raporların yeniden gönderilmesini veya alıcı başına durumu okumayı isteyebilir misiniz?
• Sıralama ve mükerrer kayıtlar hakkında dürüst rehberlik. Olaylar sırasız ve birden fazla kez gelebilir. Bunu söyleyen dokümantasyon, görmezden gelenden daha güvenilirdir.
• Uç nokta güvenliği. Webhook'ların imzalanıp imzalanmadığını sorun. İmzalanmıyorsa sağlayıcı, uç noktanın nasıl korunacağını açıklamalıdır; örneğin yalnızca HTTPS, tahmin edilemez bir yol, sıkı gövde doğrulaması ve geri alınamaz eylemlerden önce durumu teyit etme.

Nasıl bir kimlik doğrulama ve güvenlik beklemelisiniz?

En azından: TLS üzerinden Authorization başlığında gönderilen, URL'lerde asla yer almayan belirteçler; kimlik bilgilerini döndürmek ve iptal etmek için net bir süreç; ve bağımsız olarak denetlenen güvenlik kontrolleri. Bearer belirteçleri RFC 6750'de tanımlanır ve OWASP API Güvenliği İlk 10 listesi, tedarikçiyle birlikte gözden geçirmek için iyi bir listedir.

Sorun:

• Belirteçler nasıl verilir, kapsamlandırılır ve iptal edilir? Hizmet veya ortam başına ayrı belirteçleriniz olabilir mi? Sızan bir belirteç ne kadar hızlı iptal edilir?
• Kimlik bilgileri hiç URL parametresi olarak geçiriliyor mu? Bazı eski HTTP API'leri hâlâ sorgu dizesinde kullanıcı adı ve parola alır; bunlar günlüklere düşer. Yeni entegrasyonlar için bundan kaçının.
• IP izin listesi mevcut mu ve nerede? SMPP bind'lerinde yaygındır; REST için de geçerli olup olmadığını kontrol edin.
• Hizmeti hangi sertifikalar kapsıyor? Yalnızca bir logoyu değil, sertifikayı veya raporu isteyin ve kapsamı kontrol edin.
• Mesaj içeriği nerede ve ne kadar süre saklanıyor? Bu, veri koruma incelemeleri için önemlidir.

Hangi hız limitleri ve verimlilik için plan yapmalısınız?

Belgelenmiş varsayılan limitleri, bunları aştığınızda Retry-After başlığıyla bir 429 Too Many Requests yanıtını (RFC 6585) ve üretim zirveleri için daha yüksek tavanlar üzerinde anlaşma sürecini bekleyin. Belgelenmemiş limitler, en büyük kampanyanız sırasında keşfedilir.

• Arayüz başına limitleri sorun: REST istekleri, SMPP bind'leri ve sorgulama çağrılarının çoğu zaman ayrı limitleri vardır.
• Toplu uç noktaları kontrol edin. Alıcı dosyasıyla tek bir istek göndermek, binlerce tek istekten limitlere karşı daha nazikçedir.
• Zirvelerin nasıl ele alındığını sorun. Flaş indirimler ve olay uyarıları, umutla değil sağlayıcıyla birlikte planlamayı gerektirir.
• Kendi tarafınızı planlayın. API'nin önündeki bir kuyruk ve bir token-bucket sınırlayıcı, birkaç çalışanı payınızın içinde tutar.

Hatalar ve limitler referansımız bu dokümantasyonun pratikte nasıl göründüğünü gösterir.

SDK'lar ve dokümantasyon ne kadar iyi?

İyi dokümantasyon, bir mühendisin destek talebi açmadan gerçek bir mesaj göndermesini, bir durum almasını ve bir hatayı ele almasını sağlar. OpenAPI belgesini isteyin; bir tane bakımını yapan sağlayıcı size üretilmiş istemciler, Postman koleksiyonları ve doğru alan adları verebilir.

Kalite işaretleri:

• canlı API ile eşleşen bir OpenAPI 3.x şeması;
• bakımı yapılan en az bir SDK ve diğer diller için düz HTTP örnekleri;
• kesin istek alan adları, makine tarafından okunabilir bir koda sahip belgelenmiş bir hata gövdesi ve yanıt örnekleri;
• yalnızca "200 OK" ile değil, bir iletim durumuyla biten bir hızlı başlangıç;
• nelerin desteklenmediğine dair dürüst notlar.

API yeniden denemeleri ve mükerrer kayıtları nasıl ele alır?

Bir gönderim isteği sunucuda başarılı olurken yanıt kaybolabilir; bu yüzden kör bir yeniden deneme müşteriye aynı mesajı iki kez gönderir. Sağlayıcının bunu nasıl önlemenizi beklediğini sorun.

Bazı API'ler bir idempotency anahtarı kabul eder: isteğe benzersiz bir değer gönderirsiniz ve aynı değerle yapılan tekrar, orijinal sonucu döndürür. Bizimki dahil diğerleri kabul etmez; belgelenmiş desen o zaman her gönderimi yapmadan önce veritabanınıza kaydetmek, dönen mesaj kimliğini saklamak ve zaman aşımından sonra yeniden göndermeden önce kabul kanıtı olup olmadığını kontrol etmektir. Belgelenmişse iki yaklaşım da işe yarar. İşe yaramayan, bunu hiç düşünmemiş bir sağlayıcıdır. Hatalar ve limitler sayfası göndermeden önce kaydetme desenini gösterir.

Güvenli test erişimi var mı?

Trafiğin müşterilere ulaşmasından önce, kontrol ettiğiniz numaralara gerçek mesajlarla test edebilmelisiniz. Test erişiminin nasıl göründüğünü sorun: yanıtları simüle eden bir sandbox mu, yoksa doğrulanmış numaralarla sınırlı gerçek gönderimler mi.

Simüle edilmiş sandbox'lar birim testleri için yararlıdır ancak operatör davranışını nadiren yeniden üretir. Doğrulanmış numaralara yapılan gerçek gönderimler size gerçek SMS başlığı görüntüsünü, kodlamayı ve raporları gösterir. Testten üretim erişimine geçişin ne kadar sürdüğünü sorun; çünkü bazı ülkelerde SMS başlığı onayları düzenleyicinin takvimine göre ilerler.

Bir SMPP seçeneğine ihtiyacınız var mı?

Muhtemelen ilk gün değil, ama daha sonra olabilir. SMPP v3.4, kalıcı bir bağlantı üzerinden SMS alışverişi için telekom protokolüdür ve yüksek, sürekli SMS hacmine, toplayıcılara ve bayilere uygundur. Sağlayıcının TLS üzerinden SMPP sunup sunmadığını, bind'lerin nasıl devreye alındığını ve REST ile aynı rotaların kullanılıp kullanılmadığını sorun. SMS API ve SMPP rehberimiz ikisini ayrıntılı karşılaştırır.

Yapay zeka asistanları API'yi güvenle kullanabilir mi?

Ekipleriniz yapay zeka asistanları kullanıyor veya asistan geliştiriyorsa, bir Model Context Protocol (MCP) sunucusu özel yapıştırıcı kod olmadan mesajlaşma araçlarını keşfetmelerine ve çağırmalarına olanak tanır. Asistanın neler yapabileceğini ve hangi izinlerle yapabileceğini sorun.

Sorulacak sorular:

• MCP sunucusu, kendi kodumuzla aynı belirteç ve izinlerle mi çalışıyor?
• Bir asistanın yalnızca ihtiyaç duyduğu araçları, örneğin gönderim araçları olmadan iletim raporlarını etkinleştirebilir miyiz?
• Denemeler için geçici anahtarlar mevcut mu?
• Gönderimler aynı iletim raporlarında görünecek mi, böylece asistan davranışını denetleyebilir miyiz?

Bu kontrollerin bir örneği için MCP sunucusu dokümantasyonumuza bakın.

Sağlayıcı hangi uyum desteğini sunmalı?

Sağlayıcı, gerektiği yerde SMS başlıklarını kaydetmenize yardımcı olmalı, abonelikten çıkış yönetimini desteklemeli ve verileri tanınmış güvenlik ve gizlilik kontrolleri altında işlemelidir. İzinden siz sorumlu kalırsınız; sağlayıcı bunu pratik kılmalıdır.

• SMS başlıkları: bazı ülkeler alfanümerik SMS başlıklarının kaydını, bazıları da her mesajda düzenleyici kimlik gerektirir. BAE ve Suudi Arabistan SMS başlığı kayıt rehberimize bakın.
• İzin: iki yönlü SMS'te abonelikten çıkışların nasıl yakalandığını ve sistemlerinize nasıl ulaştığını sorun. İzin rehberimiz yükümlülükleri ele alır.
• Veri koruma: veri işleme sözleşmeleri, barındırma konumu, saklama ve alt işleyiciler hakkında sorun.

Destek ve SLA hakkında neler sormalısınız?

Destek koşullarını ürünün bir parçası olarak ele alın ve yazılı alın. Satış materyalindeki başlık rakamlarını karşılaştırmayın; sözleşmenin neyi taahhüt ettiğini karşılaştırın.

• Olaylar nasıl tespit edilir, iletilir ve kapatılır?
• Destek hangi saatleri, saat dilimlerini ve dilleri kapsar?
• Bir ülkede engellenen SMS başlığı gibi operatör tarafı sorunlarını kim ele alır?
• Entegrasyon sırasında adı belli bir irtibat kişisi veya devreye alma mühendisi var mı?
• Sözleşme neyi taahhüt ediyor, nasıl ölçülüyor ve yerine getirilmezse ne olur?

Fiyatlandırma ne kadar şeffaf?

Yayımlanmış bir fiyat listesinden ve hacimlerinizden aylık faturayı tahmin edebilmelisiniz. Sorun:

• Fiyatlar mesaj başına mı, segment başına mı yoksa iletilen mesaj başına mı ve bu kanala göre değişiyor mu?
• Meta'nın WhatsApp ücretleri gibi hangi üçüncü taraf ücretleri ayrı olarak yansıtılıyor?
• Faturalandırma ön ödemeli mi, sonradan ödemeli mi ve kampanyanın ortasında kredi bittiğinde ne olur?
• Numara sorgulama, SMS başlığı kaydı ve ayrılmış SMPP bind'leri ayrıca ücretlendiriliyor mu?

Unicode ve uzun mesajların daha fazla SMS segmenti kullandığını unutmayın. Karakter sınırları rehberimiz, bir Arapça kampanyanın neden İngilizce sürümünden daha pahalıya gelebileceğini açıklar.

Sağlayıcıları nasıl puanlarsınız?

Kısa listedeki her sağlayıcıyla aynı uygulamalı testi çalıştırın, ardından hepsini tek bir tabloda puanlayın. Ölçütleri kendi önceliklerinize göre ağırlıklandırın; aşağıdaki ağırlıklar bir standart değil, bir başlangıç noktasıdır.

Puanlama prosedürü

1. Kanallarınızı ve ülkelerinizi kapsayan iki ila dört sağlayıcıyı kısa listeye alın.
2. Her birinden test erişimi isteyin ve ne kadar sürdüğünü not edin.
3. Her sağlayıcıyla aşağıdaki duman testini çalıştırın.
4. En önemli pazarlarınızdaki her büyük operatörde gerçek cihazlara gönderin.
5. Yukarıdaki her bölümdeki yazılı soruları sorun.
6. Her ölçütü 1'den 5'e kadar puanlayın, ağırlıkla çarpın ve toplayın.
7. En yüksek iki puanı güvenlik, finans ve entegrasyonu yürütecek ekiple gözden geçirin.

Kısa bir duman testi

Her sağlayıcının dokümantasyonu buna benzer bir şey yapmanıza izin vermelidir. İşte hızlı başlangıçta gösterildiği gibi API'mize karşı eşdeğer çağrı:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "447700900123",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

Başarılı bir çağrı, mesaj kimliğini düz metin olarak içeren 200 OK döndürür. Test sırasında dört şeyi daha kontrol edin: kasıtlı olarak geçersiz bir belirteçle ne olduğunu (401 bekleyin), hatalı biçimli bir numarayla ne olduğunu (bir hata koduyla 400 bekleyin), bir Arapça mesajla ne olduğunu (Unicode olarak gönderilmelidir; bkz. SMS API referansı) ve bir DELIVERED durumunun webhook'unuza ulaşıp ulaşmadığını.

Uygulamalı örnek: Bir fintek OTP ve uyarı sağlayıcısı seçiyor

Suudi Arabistan ve BAE'de bir ödeme uygulaması olan "Nakheel Pay" (kurgusal), şimdi SMS OTP'ye ve bir yıl içinde WhatsApp işlem uyarılarına ihtiyaç duyuyor.

• Kısa liste: her iki ülkeyi ve her iki kanalı kapsayan üç sağlayıcı.
• Duman testi: bir sağlayıcının test erişimi günler içinde geliyor; bir başkası herhangi bir test öncesinde uzun bir satış süreci gerektiriyor. Bu, test erişimi altında kaydediliyor.
• Cihaz testleri: bir sağlayıcıda test edilen her operatörde kayıtlı SMS başlığı görünüyor; bir başkasında bir operatör numerik bir gönderici gösteriyor. Bu sağlayıcıya rotası soruluyor ve rota kalitesinde düşük puan alıyor.
• Mükerrer kayıtlar: ekip her sağlayıcının yeniden denemeleri nasıl ele aldığını doğruluyor. Biri bir idempotency anahtarı kabul ediyor; diğeri göndermeden önce kaydetme desenini belgeliyor. İkisi de kabul edilebilir; ekip deseni gönderim servisinde bir kez kuruyor.
• Güvenlik incelemesi: güvenlik ekibi sertifika kapsamlarını ve belirteç iptal sürecini kontrol ediyor.
• Karar: ağırlıklı tablo, başka bir sağlayıcının vitrin SMS fiyatı biraz daha düşük olsa da, doğrudan rotaları, normalleştirilmiş webhook'ları ve ileride büyüme için SMPP seçeneği olan sağlayıcıyı öne çıkarıyor.

Mesajlaşma API'si seçerken sık yapılan hatalar

• Yalnızca mesaj başına fiyata göre seçmek. İletilmeyen mesajlar ve değiştirilen SMS başlıkları, kazandırdığından fazlasına mal olur.
• Yalnızca simüle edilmiş bir sandbox'ta test etmek. Operatör davranışı yalnızca gerçek cihazlarda ortaya çıkar.
• Mükerrer kayıtları göz ardı etmek. Korumasız bir yeniden deneme döngüsü OTP'leri iki kez gönderir.
• "Gönderildi"yi "iletildi" saymak. Nihai durumların nasıl raporlandığını sorun.
• Sağlayıcı değiştirmenin pahalı olduğu entegrasyondan sonraya kadar güvenlik incelemesini atlamak.
• Sözlü taahhütleri kabul etmek. Destek ve hizmet koşulları sözleşmeye aittir.
• Bu kontrol listesinin sınırları: iyi uygulamayı anlatır, hukuki tavsiye değildir. Ülke kurallarını düzenleyicilerle ve sağlayıcınızla teyit edin.

OmniChannels.ai nasıl yardımcı olur?

OmniChannels.ai, SMS, WhatsApp, RCS, Messenger, Instagram, Telegram, e-posta ve push için https://api.broadnet.me adresinde tek bir REST API sunar; Bearer belirteç kimlik doğrulaması, yaklaşık 330 belgelenmiş yol, bir OpenAPI 3.1 şeması ve TypeScript SDK'sı @broadnet/cpaas-sdk ile. İletim durumları webhook'unuza tek bir biçimde ulaşır. Yüksek hacimli SMS için TLS üzerinden SMPP 3.4 mevcuttur ve bir MCP sunucusu yapay zeka asistanlarının aynı API'yi kullanmasını sağlar. Trafik, BroadNet'in 1.000'den fazla operatör ve toplayıcıyla doğrudan bağlantıları üzerinden çalışır. Test erişimi sizin doğrulanmış numaralarınıza gider; geliştirici genel bakışıyla başlayın.