فون نمبر کی ڈائریکٹری اندراج کی درخواست جمع کرائیں

آپریٹر کی ڈائریکٹری میں اندراج کی درخواست جمع کرائیں

MultiTEL میں اپنی ملکیت کے کسی اہل فون نمبر کے ڈائریکٹری اندراج کے لیے نام اور پتہ جمع کرائیں۔ یہ آپریٹر کے ہاں فیس کے عوض کی جانے والی تازہ کاری ہے، کال کرنے والے کا نام تلاش کرنا، نجی رابطہ فہرست میں اندراج کرنا یا پورٹل کی انوینٹری کے LIDB خانے کی عمومی تازہ کاری کرنا نہیں ہے۔

صرف وہی تفصیلات جمع کرائیں جنہیں صارف نے ڈائریکٹری اندراج کے لیے مجاز قرار دیا ہو۔ اس پرانے روٹ کو استعمال کرنے سے پہلے تصدیق کریں کہ آپریٹر اس نمبر کے لیے یہ سہولت فراہم کرتا ہے۔ جس ہینڈلر کا جائزہ لیا گیا ہے وہ فراہم کنندہ کی اہلیت یا بین الاقوامی نمبر کی ساخت کی توثیق نہیں کرتا؛ آپریٹر کو بھیجی جانے والی اس کی درخواست نمبر کو شمالی امریکا کا نمبر فرض کرتی ہے اور محفوظ شدہ پہلا ہندسہ ہٹا دیتی ہے۔

اکاؤنٹ اور نمبر کے تقاضے

اجازت یافتہ ماخذ IP پتے سے HTTPS کے ذریعے فعال API اکاؤنٹ استعمال کریں۔ عین یہی نمبر اس اکاؤنٹ کی خریدے گئے نمبروں کی کسی ایسی قطار میں ہونا چاہیے جو کالعدم نہ ہو۔ اپنی انوینٹری میں موجود مکمل بین الاقوامی ہندسے استعمال کریں، مثلاً معاونت یافتہ شمالی امریکی نمبر کے لیے ملکی کوڈ 1 والی ساخت۔ قیمت کے منصوبے کی شناخت، نمبر کا UUID یا کسی دوسرے اکاؤنٹ کا نمبر استعمال نہ کریں۔

فارم کی POST درخواست

یہ قدر مقرر کریں: NUMBER کو اپنی ملکیت والے نمبر پر مقرر کریں۔ فرضی مثال کی جگہ اندراج کی مجاز معلومات درج کریں۔ یہ روٹ POST سے فارم کے خانے پڑھتا ہے؛ یہ application/json ساخت والے درخواست کے متن کی پارسنگ نہیں کرتا۔

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"

مثال میں دی گئی سمتیں اور پتہ صرف نمونے کی قدریں ہیں، تجویز کردہ ڈاک کا پتہ نہیں۔ صارف کی حقیقی معلومات میں فرضی سمت شامل نہ کریں۔ API میں لازمی خانوں کی جانچ سطحی ہے: اس سے یہ ثابت نہیں ہوتا کہ پتہ درست ہے یا آپریٹر اسے قبول کرتا ہے، اور پرانی ویب سائٹ پر فارم کے مختلف تقاضے لاگو تھے۔

اگر سمت کا کوئی اختیاری جزو موجود نہ ہو یا خالی ہو تو موجودہ نفاذ صف میں کلید غائب ہونے کی تنبیہ دے سکتا ہے۔ اگر جواب کی ساخت خراب ہو یا آپریٹر پتہ مسترد کر دے تو درخواست کا حوالہ محفوظ رکھیں اور پتے کے بدلے ہوئے اندازے بار بار بھیجنے کے بجائے معاونت سے اندراج کی تصدیق کرائیں۔

چارج اور دوبارہ کوشش کا طریقہ

جائزہ لیا گیا ہینڈلر کم از کم یہ بیلنس موجود ہونے کی جانچ کرتا ہے: 10.00 بیلنس یونٹ، اور یہ جانچ آپریٹر سے رابطہ کرنے سے پہلے ہوتی ہے۔ آپریٹر کی جانب سے کامیابی اور مقامی نمبر کی تازہ کاری کی جانب سے کامیابی کی اطلاع ملنے کے بعد، یہ درج ذیل رقم منہا کرتا ہے: 10.00، جو اکاؤنٹ کے بیلنس سے کاٹی جاتی ہے، اور ڈائریکٹری اندراج قائم کرنے کا مالی لین دین درج کرتا ہے۔ یہ فی الحال نافذ شدہ رقوم ہیں، قیمتوں کی کوئی نئی تجویز نہیں؛ درخواست جمع کرانے سے پہلے اپنے اکاؤنٹ کی شرائط کے مطابق قابل اطلاق بلنگ کرنسی اور معاونت یافتہ سروس کی تصدیق کریں۔

اس کارروائی میں ایسی کلید نہیں جو درخواست دہرانے پر اضافی اثر روکے، نہ دہرے آرڈر سے بچاؤ کا انتظام ہے، اور نہ آپریٹر کو درخواست بھیجنے، مقامی تازہ کاری اور بلنگ کو محیط کوئی مشترکہ ٹرانزیکشن ہے۔ کامیاب ہونے والی دہرائی گئی درخواست آپریٹر کو ایک اور درخواست بھیج سکتی ہے اور ایک اور چارج لگا سکتی ہے۔ مقررہ وقت ختم ہونا یا API کی خرابی یہ ثابت نہیں کرتی کہ آپریٹر نے پہلی درخواست مسترد کر دی تھی: ممکن ہے فراہم کنندہ نے مقامی تازہ کاری ناکام ہونے سے پہلے اسے قبول کر لیا ہو۔

جواب

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

عام کامیاب جواب میں خالی سٹرنگ والا یہ خانہ ہوتا ہے: response، اور اندراج کی کوئی شناخت یا تکمیل کی تفصیلات واپس نہیں آتیں۔ اس کا مطلب ہے کہ آپریٹر اور مقامی تازہ کاری کے راستوں نے کامیابی کی اطلاع دی؛ یہ ہر بیرونی ڈائریکٹری میں اشاعت، فوری پھیلاؤ یا آئندہ کال کرنے والے کی شناخت دکھائے جانے کا ثبوت نہیں ہے۔

پرانے نظام کی خرابیاں

HTTP کی حیثیت اور JSON کے درج ذیل خانے، دونوں پڑھیں: status.code/status.msg۔ شناخت کی توثیق اور ماخذ IP کی پابندیاں بھی قابل استعمال جواب ملنے سے روک سکتی ہیں۔ صرف اس وجہ سے تازہ کاری کی درخواست کے لیے GET یا استفساری پیرامیٹر استعمال نہ کریں کہ پرانے ہینڈلر میں HTTP کے طریقے پر واضح پابندی لگانے والا انتظام موجود نہیں۔

دوبارہ کوشش سے پہلے تصدیق کریں

1. درخواست بھیجنے سے پہلے اپنی ملکیت والے نمبر، آپریٹر کی اہلیت، اندراج کی مجاز معلومات اور چارج کی تصدیق کریں۔
2. درخواست ایک بار جمع کرائیں اور اکاؤنٹ کی جانب حاصل ہونے والا نتیجہ محفوظ رکھیں، صارف کا پتہ عوامی لاگز یا تجزیاتی نظاموں میں ظاہر نہ کریں۔
3. اکاؤنٹ کے معاونت یافتہ طریقۂ کار یا معاونت کی مدد سے محفوظ شدہ اندراج اور مالی لین دین کی سابقہ تفصیلات دیکھیں۔ آپریٹر کے تصدیق شدہ کارروائی کے وقت تک انتظار کریں؛ یہ API معلومات کے پھیلاؤ کی کوئی ضمانت شدہ آخری مدت مقرر نہیں کرتا۔
4. جب نتیجہ غیر یقینی ہو تو دوبارہ کوشش کرنے سے پہلے معاونت سے آپریٹر کے آرڈر اور مقامی بلنگ کی تطبیق کرائیں۔ دہرائی گئی درخواست حیثیت کی ایسی جانچ نہیں ہے جسے دہرانے سے کوئی اضافی اثر نہ پڑے۔