मैसेजिंग ब्रांड अपडेट करें

मौजूदा मैसेजिंग ब्रांड की जानकारी सुधारें

व्यवसाय के संपर्क विवरण या पते में बदलाव होने पर मौजूदा ब्रांड को अपडेट करें। उसकी ब्रांड आईडी बनाए रखें; मौजूदा व्यवसाय की जानकारी सुधारने के लिए दूसरा पंजीकरण बनाना सही तरीका नहीं है। अनुमत स्रोत आईपी पते से 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 सुरक्षित रखें और दोबारा सबमिट करने से पहले मौजूदा रिकॉर्ड पढ़ें।

अपडेट का उत्तर खाली न होने पर भी अधूरा हो सकता है, जिससे स्थानीय स्नैपशॉट अधूरा रह सकता है; सफलता के खाली उत्तर से स्नैपशॉट में पुराने फ़ील्ड बने रह सकते हैं। केवल सफलता की स्थिति देखकर यह न मानें कि फ़ील्ड सुरक्षित रखे गए हैं। ब्रांड का पूरा रिकॉर्ड दोबारा पढ़ें और किसी भी अंतर को सहायता टीम के माध्यम से सुलझाएँ। यह मार्गदर्शिका रजिस्ट्री, स्थानीय कैश और बिलिंग के अपडेट को एक अविभाज्य कार्रवाई के रूप में पूरा करने का वादा नहीं करती।