Kaydolun ve 100 ücretsiz kontrol almak için destekle iletişime geçin.Ücretsiz kaydol
Operatör Sorgulama API: Kayıt Arka Ucuna Operatör ve Hat Türü Bağlamı Ekleme konulu CarrierLookup iş akışı görseli
Bu CarrierLookup makalesinde ele alınan iş akışına görsel bir genel bakış.

Telefonla kayıt işleminden sonra bir operatör sorgulama API'sini çağırmak, orijinal operatörü ve hat türünü inceleme bağlamı olarak saklamak ve hataları güvenli bir şekilde yönetmek için bir arka uç entegrasyon kılavuzu.

Telefonla kayıt akışındaki bir operatör sorgulama API'si, gönderilen numarayı alan ve numara aralığının orijinal olarak tahsis edildiği operatörü, numara türünü ve tahsis coğrafyasını döndüren bir sunucu tarafı çağrısıdır. CarrierLookup ile arka uç, numarayı E.164 formatına normalleştirir, sunucuda tutulan bir API anahtarıyla POST /api/v1/check adresine gönderir ve sonucu inceleme bağlamı olarak hesabın yanında saklar. En iyi yerleşim, form kabul edildikten sonra ve herhangi bir yönlendirme veya manuel inceleme kararından öncedir; böylece yavaş veya Belirlenemedi bir sorgulama, kullanıcının kaydı tamamlamasını asla engellemez.

Telefon numarası sorgulama vs IP tabanlı operatör tespiti

Operatör sorgulama API'si aramaları iki farklı hizmet türü döndürür ve yanlış olanı seçmek bir entegrasyon sprintini boşa harcar.

Soru IP tabanlı tespit Telefon numarası operatör sorgulama
Girdi Ziyaretçinin IP adresi veya istek başlıkları E.164 formatında bir telefon numarası
Ne tanımlar Mevcut web oturumunun geldiği mobil ağ Numara aralığının orijinal olarak tahsis edildiği operatör
Ne zaman değişir Ziyaretçi Wi-Fi, VPN veya ağ değiştirdiğinde Numara tahsisi değiştiğinde (nadir görülür)
Tipik kullanım İçerik uyarlama, trafik analitiği İletişim verisi bağlamı, yönlendirme testleri, inceleme kuyrukları

Bir kişinin yazdığı telefon numarasını anlamak isteyen bir kayıt arka ucu, ikinci türe ihtiyaç duyar. Bir IP sorgulaması numara hakkında hiçbir şey söylemez ve bir numara sorgulaması da tarama oturumu hakkında hiçbir şey söylemez. Bazı ekipler her ikisini de saklar, ancak bunlar farklı soruları yanıtlar ve ayrı adlarla ayrı alanlarda tutulmalıdır.

Operatör sorgulama API çağrısı kayıt sürecinde nereye yerleştirilmelidir?

Sorgulamayı arka uçta, kendi form doğrulamanızdan sonra ve çıktısını kullanan herhangi bir karardan önce yerleştirin. Çoğu ürün için çalışan bir sıra:

  1. Formu kabul edin. Telefon alanının mevcut ve makul bir şekilde biçimlendirilmiş olduğunu kontrol edin.
  2. E.164 formatına normalleştirin. Girdiyi, ITU-T E.164 standardında tanımlandığı gibi boşluksuz, artı işareti, ülke kodu ve abone rakamları olacak şekilde dönüştürün. Senkron sorgulamalar ayrı bir ülke seçimine ihtiyaç duymaz, bu nedenle numaranın içindeki ülke kodu bu bilgiyi taşır.
  3. Hesabı bekleyen bağlam durumunda oluşturun. Kayıt sayfanızın sıkı bir gecikme bütçesi varsa, sorgulama sırasında HTTP yanıtını açık tutmayın.
  4. POST /api/v1/check çağrısını yapın. Bir iş veya çalışan (worker) üzerinden tek bir numara ile çağrıyı gerçekleştirin.
  5. Sonucu saklayın. Sorgulama zamanı ve tamamlandı, boş veya Belirlenemedi gibi bir durumla birlikte sonucu kaydedin.
  6. Kendi kurallarınızı uygulayın. Hesabı yönlendirin, manuel inceleme kuyruğuna ekleyin veya hiçbir şey yapmayın.

Çağrıyı bir kuyrukta çalıştırmak, kayıt sürecini hızlı tutar ve yeniden denemeler için doğal bir alan sağlar.

Her sorgulamadan ne saklanmalı?

Tamamlanmış bir kontrol, numaranın tahsisini açık terimlerle tanımlar: orijinal operatör, bir marka başka bir ağ üzerinde çalıştığında altta yatan operatör, mobil veya sabit hat gibi numara türü, ülke kodu ve aralığa bağlı bölge ve şehir. Bunları, carrier yerine original_carrier ve location yerine allocation_region gibi ne olduklarını belirten alan adlarında saklayın. Bölge ve şehir, aralığın nereye tahsis edildiğini tanımlar; bu, kaydolan kişinin bulunduğu yer değildir.

Bunların yanında üç değer daha tutun:

  • Sorgulama zaman damgası, böylece inceleyenler bağlamın ne kadar eski olduğunu bilir.
  • Sonuç: değerlerle tamamlandı, boş değerlerle tamamlandı veya Belirlenemedi.
  • Gönderilen girdi, tam E.164 dizisi; bu, sonraki denetimleri ve yeniden kontrolleri basitleştirir.

Tamamlanmış bir sonuç, her operatör alanı boş olarak dönebilir. Bunu bir hata olarak değil, tamamlandı-boş olarak kaydedin ve hesap hakkında herhangi bir kanıt olarak değerlendirmeyin. Bu ayrım, daha sonra bu alanların üzerinde bir gösterge paneli oluşturulduğunda önemlidir.

Zaman aşımlarını, Belirlenemedi sonuçlarını ve reddedilen girdileri yönetme

Üç hata şekli farklı kod yolları gerektirir ve bunları birleştirmek en yaygın entegrasyon hatasıdır.

Durum Ne anlama gelir Arka uç eylemi
Girdi format nedeniyle reddedildi Dizi geçerli bir E.164 değildi Normalleştirmeyi düzeltin; operatör sonucu kaydetmeyin
Belirlenemedi sonuç (sıfır olmayan iş kodu) Kontrol bir sonuca ulaşamadı Belirlenemedi olarak işaretleyin, daha sonra kademeli olarak tekrar deneyin
İstek zaman aşımına uğradı Belgelenen üst sınır içinde yanıt yok Belirlenemedi gibi davranın; kuyruktan tekrar deneyin

Genel API, tekli ve çoklu istekler için zaman aşımı üst sınırlarını ve hesap başına sınırlı sayıda paylaşılan eşzamanlı senkron yuva sayısını belgeler. Trafik artışları sırasında kayıt başına paralel olarak bir istek göndermek yerine, çalışan eşzamanlılığınızı bu paylaşılan bütçenin altında tutun. Başarısız veya Belirlenemedi sorgulamalar ücretlendirilmez, bu nedenle bir yeniden deneme politikasının çift faturalandırma konusunda endişelenmesine gerek yoktur, ancak yine de denemeleri sınırlandırmalıdır (örneğin bir saate yayılmış üç deneme) ve ardından hesabı bir inceleyen için Belirlenemedi durumunda bırakmalıdır.

API anahtarını sunucuda tutma

REST API, yalnızca güvenilir bir sunucudan gönderilmesi gereken bir X-API-Key başlığı ile kimlik doğrulaması yapar. Sorgulamayı asla tarayıcı JavaScript'inden veya bir mobil uygulama paketinden çağırmayın; istemciye gönderilen bir anahtarı herkes ele geçirebilir ve bakiyenizi harcayabilir.

OWASP Secrets Management Cheat Sheet ile uyumlu pratik kontroller:

  • Anahtarı kaynak kodundan değil, bir gizli yönetim sisteminden veya dağıtım platformunun gizli deposundan yükleyin.
  • Ona yalnızca sorgulama çalışanına okuma erişimi verin.
  • Belirli bir programda ve şüpheli bir sızıntıdan hemen sonra anahtarı döndürün.
  • Anahtarı veya tam istek başlıklarını asla uygulama günlüklerine yazmayın.
  • Ücretlendirme yapmadan bakiyeyi okuyan GET /api/v1/balance ile hesap bakiyesini izleyin ve kayıt hacmiyle eşleşmeyen ani düşüşlerde uyarı verin.

Tetikleyicinin kendisini de koruyun. Otomatik form gönderimlerinin ücretli sorgulama akışına dönüşmemesi için kendi kayıt uç noktanızı hız sınırlamasına (rate-limit) tabi tutun.

Sonucu yönlendirme ve incelemede kullanma

Operatör ve hat türünü, ekibinizin sahip olduğu kurallara girdi olarak değerlendirin, karar olarak değil. Ekiplerin kullandığı bazı örnekler:

  • Yönlendirme testleri. Yeni hesapları orijinal operatöre göre gruplandırın ve farklı mesajlaşma sağlayıcılarının her grup için kendi metriklerinizde nasıl performans gösterdiğini karşılaştırın.
  • İnceleme kuyrukları. Hat türü ürünün beklediğinin dışında olan hesapları (örneğin mobil öncelikli bir uygulamada sabit hat numarası), bağlam eklenmiş olarak bir inceleyene gönderin.
  • Veri kalitesi. Numaranın ülke kodu ile formda seçilen ülkenin uyuşmadığı kayıtları işaretleyin, böylece destek ekibi düzeltme isteyebilir.

Kuralları yazılı hale getirin ve geri döndürülebilir tutun. İşaretli bir hesaba bakan bir inceleyen, sorgulama değerlerini, sorgulama zamanını ve tetiklenen kuralı görmelidir. Operatör orijinal tahsisi yansıttığından, bir sonuç asla bir telefonun kod alabileceğine veya kaydolan kişiye ait olduğuna dair tek başına bir kanıt oluşturmaz; bunu mevcut doğrulama adımınızla eşleştirin.

SSS

Ekipler, entegrasyondan önce kaydolan birçok mevcut hesabı nasıl kontrol edebilir?

İstek başına 100 E.164 numarasına kadar olan eski kayıtlar için POST /api/v1/batch-check kullanın. Sonuçlar girdi sırasına göre geri döner ve her satır normal bir sonucun mevcut olup olmadığını belirtir. Normal sonucu olmayan satırlar, boş olarak kaydedilmek yerine daha sonraki bir yeniden deneme için işaretlenmelidir. Çok büyük geçmiş listeleri, ülke başına gönderilen asenkron bir toplu dosya görevi olarak daha iyi yönetilir.

Bir arka uç, aynı numara için iki kez ödeme yapmaktan nasıl kaçınabilir?

Sorgulama zamanı ile normalleştirilmiş E.164 dizisiyle anahtarlanmış bir önbellek tutun. Bir numara yakın tarihli bir kontrolden tamamlanmış bir sonuca sahip olduğunda, API'yi tekrar çağırmak yerine bunu yeniden kullanın. Tahsis bağlamı yavaş değişir, bu nedenle birçok ekip yalnızca bir kayıt düzenlendiğinde veya saklanan sonuç birkaç ay gibi seçtikleri bir süreden daha eski olduğunda yenileme yapar.

Geliştiriciler entegrasyonu canlıya almadan önce nasıl test edebilir?

Çalışanı kendi API anahtarına ve küçük bir bakiyeye sahip bir hazırlık (staging) yapılandırmasına yönlendirin, ardından bir dizi senaryoyu betikleştirin: geçerli bir mobil numara, sabit hat numarası, E.164 normalleştirmesinde başarısız olan bir girdi ve zorunlu bir zaman aşımı. Üretim trafiğini açmadan önce her yolun beklenen sonuç durumunu yazdığını ve günlüklerde hiçbir anahtar veya başlığın görünmediğini doğrulayın.

Daha Fazla Bilgi

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

Kaynaklar