ڈیولپرز

POST/v3/update_document/{uuid}

رجسٹریشن پروفائل کو اپ ڈیٹ کریں

پروفائل کی قابل ترمیم تفصیلات مکمل طور پر جمع کرائیں اور کامیابی کے پرانے فارمیٹ کو سنبھالیں۔

اس صفحے پر
  1. پروفائل کی قابل ترمیم تفصیلات تبدیل کریں
  2. اپ ڈیٹ کی درخواست
  3. اعلیٰ ترتیبات: پہلے سے اپ لوڈ کردہ ثبوت شامل کریں
  4. کامیابی اور ناکامی کے پرانے فارمیٹ والے جوابات
  5. اپ ڈیٹ کی موجودہ حدود اور ناکامی سے بحالی

پروفائل کی قابل ترمیم تفصیلات تبدیل کریں

اکاؤنٹ کی ملکیت میں موجود رجسٹریشن پروفائل کو اپ ڈیٹ کرنے کے لیے اس کا مقامی UUID یہاں سے حاصل کریں: create_document یا documents۔ یہ کارروائی اکاؤنٹ اور بالائی سطح کے ٹیلی کام فراہم کنندہ کے ڈیٹا میں تبدیلی کرتی ہے۔ یہ محفوظ شدہ شناخت کی قسم Personal/Business کو تبدیل نہیں کرتی اور صرف کچھ فیلڈز کی تبدیلی کے لیے PATCH درخواست نہیں ہے۔

اپ ڈیٹ کی درخواست

اجازت یافتہ IP پتے سے اپنے فعال MultiTEL API اکاؤنٹ کے ذریعے توثیق کریں۔ مثالوں میں ماحولیاتی متغیرات میں رکھی گئی اسناد اور فرضی ڈیٹا استعمال کیا گیا ہے۔ HTTP جواب کے ساتھ JSON کے status.code اور status.msg بھی پڑھیں۔

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --header 'Content-Type: application/json' \
  --data @registration-profile-update.json \
  "https://api.multitel.net/v3/update_document/$DOCUMENT_UUID"
{
  "first_name": "Example",
  "last_name": "Person",
  "phone_number": "12025550123",
  "email": "end-user@example.com",
  "city": "Example City",
  "postal_code": "00000",
  "address": "1 Example Street",
  "country": "US",
  "nationality": "US",
  "signature": "BASE64_PNG_OF_THE_AUTHORIZED_END_USER_SIGNATURE",
  "id_number": "",
  "personal_tax_id": "",
  "birth_date": "",
  "description": "Example profile",
  "company_name": "",
  "company_reg_number": "",
  "incorporation_country": "",
  "vat_id": "",
  "address_description": ""
}

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

اپ ڈیٹ کے فیلڈز کی ضروریات
فیلڈزطرز عمل
first_name, last_name, city, postal_code, addressلازمی؛ ہر فیلڈ میں زیادہ سے زیادہ 64 حروف ہو سکتے ہیں۔
phone_numberکم از کم آٹھ حروف پر مشتمل عددی قدر لازمی ہے؛ ملک کے کوڈ سمیت بین الاقوامی فارمیٹ کے ہندسے استعمال کریں۔
signatureلازمی ہے۔ پورٹل ڈیٹا URL کے سابقے کے بغیر Base64 میں انکوڈ کردہ PNG بائٹس فراہم کرتا ہے۔
countryرجسٹریشن کیٹلاگ سے پتے کے ملک کا ISO کوڈ فراہم کریں۔ ہینڈلر اس کوڈ سے متعلقہ ملک متعین کرتا ہے، اگرچہ جائزہ لیے گئے پتے کے اپ ڈیٹ میں ملک سے تعلق تبدیل نہیں ہوتا۔
nationalityموجودہ Personal پروفائل کے لیے ملک کا ISO کوڈ لازمی ہے۔
company_name, incorporation_countryموجودہ Business پروفائل کے لیے لازمی ہیں؛ کمپنی کا نام زیادہ سے زیادہ 64 حروف پر مشتمل ہو اور کمپنی کے قانونی اندراج کے ملک کے لیے ISO کوڈ دیا جائے۔
emailزیادہ سے زیادہ 254 حروف پر مشتمل درست ای میل اختیاری ہے۔ محفوظ شدہ رابطے کی ای میل برقرار رکھنے کے لیے یہ فیلڈ چھوڑ دیں؛ اسے مقامی طور پر مٹانے کے لیے خالی قدر بھیجیں۔
id_number, personal_tax_id, birth_date, description, company_reg_number, vat_idمطلوبہ موجودہ قدریں بھیجیں۔ جو قدریں نہیں بھیجی جاتیں وہ طے شدہ طور پر خالی ہو جاتی ہیں اور پہلے سے محفوظ قدروں کی جگہ لکھ سکتی ہیں۔

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

اعلیٰ ترتیبات: پہلے سے اپ لوڈ کردہ ثبوت شامل کریں

اختیاری اَرے identity_encryptfiles اور address_encryptfiles اکاؤنٹ کی ملکیت میں موجود فعال حوالے اس ذریعے سے قبول کرتے ہیں: create_encrypt_files۔ اپ لوڈ کی اکائی کے زمرے سے مطابقت رکھیں اور حوالے کی میعاد ختم ہونے سے پہلے جمع کرائیں۔ ہر فائل ثبوت کی ایک الگ درخواست میں منسلک ہوتی ہے، چاہے کئی فائلوں کے ثبوت کی قسم ایک ہی ہو۔ کئی فائلوں پر مشتمل شناختی ثبوت کے لیے بعد کے مرحلے میں ثبوت منسلک کرنے کے طریقۂ کار کو ایک ہی اَرے کے ساتھ استعمال کریں۔

اگر نئے بنائے گئے پتے کے لیے بعد میں پتے کا ثبوت مسترد ہو جائے تو اس کی جگہ پروفائل کا UUID استعمال نہ کریں اور نہ ہی بار بار شناخت دوبارہ بنائیں۔ رک جائیں اور پورٹل میں یا سپورٹ کے ذریعے پروفائل چیک کریں۔ پتے کے ثبوت کو واپس پڑھنے/تلاش کرنے کا راستہ ابھی جائزے کی ایک حد ہے۔

کامیابی اور ناکامی کے پرانے فارمیٹ والے جوابات

{
  "status": {
    "code": "success",
    "msg": "Successfully Saved."
  },
  "response": ""
}

اس اینڈ پوائنٹ کی کامیابی کا معمول کا کوڈ یہ سٹرنگ ہے: success، عددی 200 نہیں۔ بالائی نظام یا مقامی نظام کی معمول کی ناکامی کے لیے یہ سٹرنگ استعمال ہو سکتی ہے: error۔ عددی کوڈ 400 غیر درست فیلڈز یا ثبوت سے متعلق ناکامیوں کو ظاہر کرتا ہے، 404 پروفائل کی عدم موجودگی یا اپ لوڈ کردہ فائل کے غیر درست حوالے کو، اور 500 درخواست کے خالی متن یا ملک متعین نہ ہو سکنے کو ظاہر کرتا ہے۔ پیغام اور جانچ کے تمام اندراجات پڑھیں؛ صرف HTTP 200 کو کامیابی نہ سمجھیں۔

اپ ڈیٹ کی موجودہ حدود اور ناکامی سے بحالی

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

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