پیغام رسانی کے برانڈ کو اپ ڈیٹ کریں

پیغام رسانی کے موجودہ برانڈ کی تفصیلات درست کریں

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

سب سے پہلے موجودہ ریکارڈ پڑھیں۔ اپنی مقامی نقل کو نجی رکھیں کیونکہ اس میں کاروبار کی شناخت اور رابطے کی معلومات شامل ہیں۔

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
  --output current-brand.json

برانڈ کے موجودہ فیلڈز برقرار رکھیں

موجودہ ریکارڈ سے brand-update.json تیار کریں اور صرف برانڈ کے وہ فیلڈز منتخب کریں جن میں لکھنے کی اجازت ہے۔ مطلوبہ تصحیح کرتے ہوئے کاروبار کی شناخت اور دیگر لازمی قدریں برقرار رکھیں۔ GET کا پورا جواب نہ بھیجیں: brandId، شناخت اور حالت کے نتائج، وقت کی مہریں اور صرف جواب میں آنے والے دیگر فیلڈز اپ ڈیٹ میں شامل نہیں ہونے چاہییں۔

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

برانڈ اپ ڈیٹ کے فیلڈز کے گروہ
فیلڈز	انہیں استعمال کرنے کا طریقہ
displayName, email, phone	قابل شناخت برانڈ نام اور درست رابطے کی تفصیلات۔ زیادہ سے زیادہ لمبائیاں: 255، 100 اور 20 حروف۔ فون نمبر کی بین الاقوامی وضع استعمال کریں جس میں + کے بعد ملک کا کوڈ آتا ہے۔
street, city, state, postalCode, country	کاروبار کا حقیقی پتہ جس کی تفصیلات باہم مطابقت رکھتی ہوں۔ حدیں: 255، 100، 20، 10 اور 2 حروف۔ جہاں قابل اطلاق ہو، امریکی ریاستوں کے موجودہ کوڈ استعمال کریں۔
entityType, companyName, ein, einIssuingCountry	قانونی شناخت۔ جب مہمات یا بیرونی جانچ زیر التوا یا فعال ہوں تو ان تبدیلیوں پر پابندیاں لاگو ہوتی ہیں۔ شناخت سے متعلق پابندی سے بچنے کے لیے کام کرنے والی مہمات حذف نہ کریں۔
firstName, lastName, mobilePhone, businessContactEmail	ادارے کی نوعیت کے مطابق شناخت کی معلومات یا تصدیق کے لیے رابطے کی تفصیلات۔ حدیں: 100، 100، 20 اور 255 حروف۔
brandRelationship, vertical	تعلق اور شعبۂ کاروبار کے موجودہ کوڈ۔ تعلق میں تبدیلی تین ماہ میں صرف ایک بار کی جا سکتی ہے۔ پورٹل کے عام ترمیمی فارم میں تعلق بدلنے کی سہولت نہیں ہے۔
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	حسب اطلاق ویب سائٹ، متبادل کاروباری شناخت اور عوامی حصص والی کمپنی کی تفصیلات۔ ادارے کی توثیق کے لیے درکار قدریں برقرار رکھیں۔
referenceId, ipAddress	کاروباری حوالے اور درخواست کے ماخذ آئی پی سے متعلق معاونت یافتہ میٹا ڈیٹا۔ ان میں سے کوئی بھی اکاؤنٹ کی ملکیت متعین نہیں کرتا اور نہ ہی درخواست کی آئیڈیم پوٹنسی کلید کا کام کرتا ہے۔

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

جائزہ شدہ تصحیح جمع کرائیں

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @brand-update.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID"

اس مطلوبہ اپ ڈیٹ کے لیے ایک ہی کلید استعمال کریں اور درخواست کے متن کے عین وہی بائٹس محفوظ رکھیں۔ طریقہ، راستہ، استفسار یا متن بدل کر اسی کلید کو دوبارہ استعمال کرنے سے تصادم ہوتا ہے؛ JSON کی وضع بدلنے سے بھی فنگرپرنٹ بدل جاتا ہے۔ زیر عمل درخواست کی نقل Retry-After کے ساتھ 409 واپس کر سکتی ہے۔ مکمل شدہ درخواست اپنا محفوظ نتیجہ دوبارہ واپس کر سکتی ہے، جس میں خرابی بھی شامل ہو سکتی ہے۔ وقت ختم ہونے کی صورت میں نتیجے کا تعین کرتے وقت خودکار طور پر نئی کلید بنانے کے بجائے درخواست کی تفصیلات محفوظ رکھیں۔

محفوظ ریکارڈ اور توثیق کی حالت کی پڑتال کریں

کامیاب اپ ڈیٹ HTTP 200 اور برانڈ کا براہ راست JSON آبجیکٹ واپس کرتی ہے، پرانے v3 کے status/response لفافے کے بغیر۔ اس کا brandId جانچیں، پھر GET کے ذریعے اسی برانڈ کو دوبارہ حاصل کریں اور مطلوبہ فیلڈز کا موازنہ کریں۔ عوامی اپ ڈیٹ کا راستہ پورٹل کا changes/version غلاف قبول نہیں کرتا اور نہ ہی بیک وقت ہونے والی تبدیلیوں کی اس کی پُرامید جانچ فراہم کرتا ہے۔ بیک وقت ترمیم کرنے والوں کے درمیان ہم آہنگی رکھیں؛ آئیڈیم پوٹنسی کلید درخواست دوبارہ جمع ہونے سے روکتی ہے، کسی دوسرے ترمیم کنندہ کی تبدیلیوں سے نہیں۔

موجودہ پورٹل برانڈ کو پڑھتا ہے، اس کے قابل تحریر فیلڈز برقرار رکھتا ہے، محفوظ کرنے سے پہلے فارم کا ورژن جانچتا ہے اور نتیجہ دوبارہ پڑھتا ہے۔ فعال مہمات ملنے پر یہ قانونی شناخت کے بنیادی فیلڈز مقفل کر دیتا ہے۔ رجسٹری اضافی پابندیاں، جن میں بیرونی جانچ سے متعلق پابندیاں بھی شامل ہیں، لاگو کر سکتی ہے، چاہے فارم نے کسی فیلڈ میں ترمیم کی سہولت دی ہو۔

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

دوبارہ رجسٹریشن کیے بغیر خرابیاں دور کریں

HTTP کی حالت اور JSON میں خرابی کی تفصیلات پڑھیں۔ 400 کے لیے مخصوص فیلڈ درست کریں یا شناخت یا تعلق سے متعلق پابندی کی پابندی کریں۔ 401، 403 یا 404 کے لیے اسناد، اجازت یافتہ ماخذ آئی پی اور اکاؤنٹ کی ملکیت جانچیں۔ 429 کے لیے Retry-After کی ہدایت پر عمل کریں۔ رجسٹری کے اپ ڈیٹ قبول کر لینے کے بعد بھی 500 یا 502 آ سکتا ہے؛ ملنے والا کوئی بھی requestId محفوظ رکھیں اور دوبارہ جمع کرانے سے پہلے موجودہ ریکارڈ پڑھیں۔

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