Skip to main content

İlk port-in rehberiniz

İki operatör runbook’u — Numarayı uçtan uca port edin ve Güvenli şekilde port-out yapın — her uç noktayı ve kenar durumu kapsar. Bu sayfa, bir numarayı ilk kez taşıdığınızda kullanacağınız daha kısa kontrol listesidir: kararları sıraya koyar, her adımın koruduğu tek şeyi adlandırır ve duran port’ları neden olan ret sebebiyle eşleştirir. Bunu bir kez okuyun, ardından port işlemini runbook sayfaları açıkken çalıştırın. Okumalar (check, get, timeline) numbers:read scope’unu; yazmalar (oluşturma, LOA yükleme/imzalama/gönderme, iptal, PIN ayarlama) numbers:write ile owner, admin veya developer rolünü gerektirir. Bu sayfa iki runbook’a yeni bir şey eklemez — onların yerine geçmez, aralarındaki haritadır. İkisi de yetkili kaynaktır.

1. Gezinilen durum makinesi

Port işleminin iki yönü de tek yönlü bir durum makinesidir. Hangi durumda olduğunuzu bilmek, hangi eylemlerin hâlâ açık olduğunu gösterir — ilk port hatalarının çoğu bir eylemin bir durum geç yapıldığı için oluşur.

Port-in (numara Orbit’e taşınıyor)

submitted → reviewing → approved → completed; rejected ve cancelled terminal dallarıdır, supplement_submitted ise taşıyıcı düzeltmenizi değerlendirirken bekleme durumudur:
  • submitted — sipariş var. İptal edilebilir (DELETE /numbers/porting/:id). Create yanıtındaki staging: "draft" işareti satırın saklandığını ancak taşıyıcıya HİÇBİR ŞEY gönderilmediğini belirtir — taslak, LOA yüklenip imzalanana kadar ilerlemez.
  • reviewing — kaybeden taşıyıcı siparişinizi ve imzalı LOA’yı tutar, CSR verilerini kontrol eder. Hâlâ iptal edilebilir. Bundan sonrası değildir.
  • approved — kaybeden taşıyıcı kabul etmiş ve genellikle FOC tarihi vermiştir. İptal artık 409 döndürür; port tamamlanır.
  • completed — numara Orbit hesabınızda tam bir kez canlıdır ve number.ported yayımlanır.
  • rejected — taşıyıcı reddetmiştir; rejectionReason çevrilmiş kodu taşır. Düzeltilebilir retler 7 günlük bir supplement penceresi açar; gönderim satırı supplement_submitted durumunda bekler, taşıyıcı kabul ederse reviewinge döner veya tekrar reddeder.
  • cancelled — port-in ve port-out için terminal daldır; bundan sonra hiçbir şey uygulanmaz.
LOA’nın üzerinde kendi üç durumlu makinesi vardır: loaSignatureStatus: draft → signed → submitted ve yalnızca ileri gider. Eski veya yanlış belgeye sahip LOA, signed sonrasında değiştirilemez — port’u iptal edip yeniden gönderin.

Port-out (numara Orbit’ten taşınıyor)

Aynı ilerleme numaranın kendi durumuyla önce kapılanır: released, suspended, parked veya port_out_pending durumlarının tümü gönderimi 409 ile reddeder; bu yüzden uçuş öncesi durum kontrolü ilk çalıştırılacak şeydir. FOC geçişinden sonra kazanan taşıyıcı numaranın sahibidir — iptal yok, geri alma yok.

2. İçe aktarma öncesi kontrol listesi — ilk API çağrısından önce

Bölüm 5’teki her ret sınıfı bu listedeki bir şeye dayanır. Gönderdikten sonra değil, göndermeden önce çalıştırın:
  1. Kaybeden taşıyıcıdan Customer Service Record (CSR) — tüzel kişi adı, hesap numarası, faturalama telefon numarası (BTN), hizmet adresi ve varsa transfer PIN’i; kelimesi kelimesine kopyalayın. Hafızadan yeniden yazmayın; NAME_MISMATCH ve ADDRESS_MISMATCH retleri neredeyse tamamen tahmin edilen CSR alanlarından çıkar.
  2. Yetkili imzacı — numarayı taşıma yetkisi olan, unvanı bulunan bir kişi ve LOA’yı imzalayacak kişi. Buradaki ad, LOA imzası ve kaybeden taşıyıcının kayıtlarıyla tam eşleşmelidir.
  3. LOA taraması — ≥200 dpi gerçek bir PDF, 30 gün içinde tarihli imza ve üzerinde listelenen tüm port numaraları. LOA_INVALID retleri burada yoğunlaşır.
  4. Orbit numaralarınızda port-out PIN’i zaten ayarlı — yenilerini getirirken elinizdekileri koruyun. 4-32 karakterlik PIN’i POST /numbers/:id/port-out-protection ile ayarlamak, tek başına bir kimlik bilgisinin port-out gönderemeyeceği anlamına gelir; eşleşen PIN olmadan taşıyıcıya ulaşmadan önce 401 reddi gelir. PIN’i ayarladığınız gün secret store’a kaydedin — kurtarma yolu yoktur, yalnızca rotasyon vardır.
  5. Ülke kurallarını bilin — ABD/Kanada numaraları canlı eşzamanlı taşınabilirlik kontrolü alır; başka yerler check-not-supported döndürür ve uygunluk manueldir. Toll-free numaralar LNP akışını hiç kullanmaz; POST /numbers/porting/toll-free/resporg ile RespOrg değişikliğiyle taşınır.
  6. Uygunluk kararı elinizde — POST /numbers/porting/pre-validate çalıştırın ve ready: true ile kapılayın. Bu çağrı taşınabilirlik kontrolü ile CSR alanlarını birlikte linter’dan geçirir.
Kontrol listesindeki herhangi bir satır çözülmediyse durun. İlk create’den önce kapı disiplini, ilk port’un üç hafta içinde reddedilen bir porta dönüşmesini engeller.

3. Adım adım — sihirbaz sırası

Panodaki Number Porting formu tam bu sırayı izler; API karşılığı runbook’tadır. Önemli olan sıranın kendisidir:
  1. Numaraları girin (satır başına bir E.164) → preflight kapısını çalıştırın. Uygun değilse ilerlemeyin.
  2. Taşıyıcı + CSR alanlarını doldurun — kaybeden taşıyıcı, hesap numarası, PIN (ABD kablosuz), yetkili imzacı, hizmet adresi — CSR’nin tam kopyaları.
  3. Taslak olarak kontrol noktası oluşturun — draft: true, isteği staging: "draft" ile yerel olarak saklar ve taşıyıcıya hiçbir şey dokundurmaz. Aynı numara setiyle yeniden oluşturma idempotent’tir; tekrar ziyaret veya yenileme kontrol noktasını çatallamaz.
  4. LOA’yı platforma yükleyin (POST /numbers/porting/:id/loa) — 10 MB altında PDF/görüntü.
  5. İmzalayın (.../loa/sign) — imzacı adı, e-posta, onay. İkinci imza 422 döndürür; buraya ikinci kez geldiyseniz başka bir sorun vardır.
  6. Gönderin (.../loa/submit) — signed durumunda geçerli tek eylem. Kaybeden taşıyıcının 7-14 iş günlük incelemesi burada başlar.
  7. FOC’u takip edin — GET /numbers/porting/:id/timeline, düz durumu zaman damgalı aşama girdilerine genişletir ve taşıyıcı bir tarih verdiği anda focDate’i ekler. status: completed olana kadar izleyin.
  8. Geçişte number.ported tam bir kez gelir — numara, satın alınmış bir DID ile aynı normal yaşam döngüsüne girer (otomatik yenileme, bırakma, yeniden atama). Port edilmiş numaradaki SMS, satın alınmış numaradakiyle aynı çalışır.
  9. Taslağı park etmeyin — taslak taşıyıcıya ulaşmaz, FOC almaz ve tamamlanmaz. Pano bu durumu tam olarak “draft — LOA pending” olarak işaretler. İmzacı yoksa veya CSR bilinmiyorsa taslağı iptal edin ve hazır olduğunuzda yeniden oluşturun; sessizce yaşlanan kontrol noktası, ilk port’un sessizce durmasının en yaygın yoludur.
Port submitted veya reviewing durumundaysa ve bir şey yanlışsa DELETE /numbers/porting/:id ile iptal edin. approved sonrasında iptal 409 döndürür — port taşıyıcının takviminde tamamlanır.

4. Durum webhook’ları — neye abone olmalı

Bir webhook uç noktası kaydedin ve yoklamak yerine port olaylarına abone olun. İlk port’u ilerleten olaylar: Teslimat en az bir kez yapılır; bu nedenle alıcınızda olay id’sine göre tekilleştirin. Olaylar gerçek zamanlı güncellemeleri sürer; günlük GET /numbers/porting + timeline taraması kaçırılanları uzlaştırır. Tam katalog Webhook Events, imza doğrulama Webhook Security sayfasındadır.

5. Yaygın retler — her biri için çözüm

GET /numbers/porting/:id/timeline, taşıyıcı ret kodlarını önem derecesi operator_fixable (kendi verinizi düzeltin), needs_carrier (kaybeden taşıyıcı çözmeli) veya fatal (numara hiç taşınamaz) olarak etiketlenmiş sade bir summary + recommendedAction biçimine çevirir. İlk port’ları durduran beş neden: fatal önem derecesindeki (NUMBER_NOT_PORTABLE) retler supplement için uygun değildir — numara kaybeden taşıyıcıda kalmalıdır. Bilinmeyen taşıyıcı kodları ham taşıyıcı metnini korur; böylece tam nedenle eskale edebilirsiniz.

6. API üzerinden izleyin — çalıştırılabilir dört çağrı

Yukarıdaki kontrol listesi uç noktaları adlandırır; burada en küçük çalıştırılabilir döngü vardır. Aynı dört çağrı cURL, Node.js, Python, Go, Ruby ve PHP’de, her birinin yaptığı işe göre kapsamlandırılmıştır (bu parçaların yansıttığı tam uç nokta referansı Number Porting). Check ve timeline okumalarında numbers:read, create’te numbers:write scope’u olan bir API anahtarı kullanın.
Webhook POST’u bundan sonra her durum geçişi için bir porting.request.* olayı gönderir — alıcınızda olay id’sine göre tekilleştirin ve number.ported’ı zaman çizelgesi durum kontrolü yerine terminal başarı sinyali olarak ele alın. Adım 2’deki taslak kontrol noktası bilerek vardır: LOA zaten imzalı ve hazırsa tek seferlik gönderim için draft: true’yu kaldırın. Her iki durumda da LOA sırası — yükle, imzala, gönder — dönen portId üzerinden ilerler ve zaman çizelgesi hareket etmeye başlar. Check çağrısı 20 req/min ile sınırlıdır; webhook alıcısını bir kez kaydedin, döngüde yeniden kaydetmeyin. Buradan sonra bölüm 3’teki kontrol listesi devralır: LOA yükleme → imzalama → gönderme, sonra takip.

Listenizi yükleyin — multipart toplu CSV

Bir avuçtan fazla numara mı port ediyorsunuz? Adım 2’de satır satır create yerine, tüm defteri file alanı altında multipart/form-data olarak POST /numbers/port-in/bulk-csv’ye verin. Listeyi şu sütunlarla port-in-batch.csv olarak kaydedin (sıra önemsizdir, başlık eşleştirme büyük-küçük harfe duyarsızdır):
Her geçerli satır kendi port talebine dönüşür ve yanıt partinin iki tarafını bildirir — her satır için LOA sırasını sürmek üzere request_ids, düzeltilip yeniden yüklenmesi gereken satırlar için validation_errors (uçuşta olan yinelenen satırlar atlanır, böylece düzeltme yüklemesi güvenlidir):
200
Sınırlar: dosya başına 2 MB, istek başına 1000 satır, 30 saniyelik işleme bütçesi ve organizasyon başına dakikada 2 istek. Virgül içeren her alanı (billing_address neredeyse her zaman ihtiyaç duyar) tırnaklayın; zorunlu bir sütunu olmayan başlık, eksik sütunları adlandıran 422 ile tüm yüklemeyi iptal eder.

LOA’yı dosyalayın — yükleyin, imzalayın, gönderin

LOA, adım 2’de dönen (veya her toplu satırdaki) port kimliği üzerinden üç ardışık çağrı olarak çalışır; her çağrı loaSignatureStatus’ı bir adım ileri taşır. ≥200 dpi gerçek bir PDF hazırlayın, imzayı 30 gün içinde tarihleyin ve her port numarasını listeleyin — LOA_INVALID retleri tam olarak bu üç noktada toplanır.
Her çağrı, LOA bir durum ilerlemiş halde port isteğini döndürür:
Upload — 201
Sign — 200
Submit — 200
Durum makinesi yalnızca ileri gider: LOA signed veya submitted olduğunda değiştirme yüklemesi reddedilir — port’u iptal edin ve düzeltilmiş belgeyle yeniden gönderin. submitted durumundan sonra adım 3’teki zaman çizelgesi devralır.

See Also