नंबर पोर्टिंग परियोजना का विवरण पढ़ें

खाते और परियोजना तक पहुँच

अनुमत आईपी पते से HTTPS के माध्यम से सक्षम API खाते का उपयोग करें। परियोजना उसी खाते की होनी चाहिए और हटाई गई नहीं होनी चाहिए। पोर्टिंग ऑर्डर की कार्यप्रणाली से मिली परियोजना की विशिष्ट पहचान का उपयोग करें, उसके संख्यात्मक डेटाबेस पहचानकर्ता या किसी फ़ोन नंबर का नहीं। अनुरोध बनाते समय परियोजना के पहचानकर्ता को यूआरएल-एन्कोड करें।

अनुरोध

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/v3/lnp/project/$PROJECT_ID"

इस प्रतिक्रिया को गोपनीय रखें

पूरी प्रतिक्रिया में उस मौजूदा दूरसंचार सेवा प्रदाता की बिलिंग जानकारी होती है जिससे नंबर पोर्ट किया जा रहा है। इसमें संग्रहीत billing_pin, बिलिंग खाता, फ़ोन, पता, कंपनी और अधिकृत संपर्क के विवरण शामिल हैं। API इन फ़ील्ड को छिपाता नहीं है। यदि आपकी कार्यप्रणाली को केवल स्थिति या नंबरों की सूची चाहिए, तो केवल वही माँगें। पूरी विस्तृत प्रतिक्रिया को ब्राउज़र के संग्रहण, विश्लेषण प्रणालियों, सार्वजनिक लॉग और सहायता के लिए लिए गए स्क्रीनशॉट में न रखें। केवल वे फ़ील्ड दिखाएँ जिनकी अधिकृत ग्राहक को आवश्यकता है।

प्रतिक्रिया की संरचना

चुनिंदा फ़ील्ड वाला काल्पनिक उदाहरण; प्रतिक्रिया में अतिरिक्त फ़ील्ड भी आ सकते हैं।

{
  "status": {
    "code": 200,
    "msg": "Project Detail"
  },
  "response": {
    "project": {
      "id": 11,
      "uniqueid": "PROJECT_EXAMPLE",
      "project_name": "Example transfer",
      "location": "US",
      "status": 0,
      "status_str": "Pending"
    },
    "counts": {
      "total": 0,
      "pending": 0,
      "in_progress": 0,
      "completed": 0,
      "rejected": 0
    },
    "numbers": [],
    "events": [],
    "uploads": []
  }
}

इस उदाहरण को जानबूझकर अधूरा रखा गया है और इसमें सभी बिलिंग प्रमाणीकरण विवरण तथा व्यक्तिगत संपर्क मान छोड़े गए हैं। उदाहरण में इन्हें न दिखाने का अर्थ यह नहीं है कि वास्तविक प्रतिक्रिया में भी इन्हें छिपाया जाता है।

परियोजना विवरण के अनुभाग
अनुभाग	सामग्री
project	पंक्ति का संख्यात्मक पहचानकर्ता, परियोजना का विशिष्ट पहचानकर्ता, परियोजना का नाम, स्थान, संग्रहीत बिलिंग/संपर्क/पते का डेटा, निर्माण समय और गणना से निकाली गई स्थिति। जिस मौजूदा सेवा प्रदाता से नंबर पोर्ट किया जा रहा है, उसके पुराने फ़ील्ड की वर्तनी loosing_carrier है।
counts	नंबरों की कुल पंक्तियाँ और Pending, In Progress, Completed तथा Rejected की गिनतियाँ।
numbers	परियोजना के नंबर-सूची एंडपॉइंट के समान नंबर-संबंधी फ़ील्ड, जिनमें ग्राहक की टिप्पणियाँ और संग्रहीत समय-निर्धारण मान भी शामिल हैं।
events	संग्रहीत इवेंट पंक्तियाँ और मूल/पार्स किए गए पेलोड फ़ील्ड; इन पर इवेंट एंडपॉइंट की दृश्यता और प्रारूप संबंधी सीमाएँ लागू होती हैं।
uploads	दस्तावेज़ का मेटाडेटा: संख्यात्मक पहचानकर्ता, upload_type, file_name, file_extension, date_created और एक सापेक्ष download_url। इस यूआरएल के लिए भी खाते का प्रमाणीकरण आवश्यक है।

सारांश और मेटाडेटा को समझें

गणना से निकाली गई स्थिति में पहले In Progress, फिर Pending, फिर Completed और फिर Rejected को प्राथमिकता दी जाती है; इनमें से कोई लागू न होने पर Pending लिया जाता है। सारांश Completed होने पर भी कुछ नंबर अस्वीकृत हो सकते हैं। हर नंबर की पोर्टिंग पूरी हो गई है, ऐसा मानने के बजाय गिनतियाँ और प्रत्येक नंबर की स्थिति जाँचें।

प्रतिक्रिया में दस्तावेज़ का मेटाडेटा होता है, फ़ाइल के बाइट नहीं। इसमें पृष्ठांकन या क्रमिक बदलाव पढ़ने वाला कर्सर नहीं है। विवरण और सूची की क्वेरी अलग-अलग पढ़ी जाती हैं; वे एक ही लेनदेन के अनुरूप होने की गारंटी वाला स्नैपशॉट नहीं हैं। तारीखें संग्रहीत मानों के रूप में ही रहती हैं और किसी समय-क्षेत्र परिवर्तन का दस्तावेज़ी उल्लेख नहीं है। परियोजना के रूट में uniqueid का उपयोग करें; उसकी जगह परियोजना का संख्यात्मक पहचानकर्ता इस्तेमाल नहीं किया जा सकता।

त्रुटियाँ और सीमाएँ

इन दोनों की जाँच करें: HTTP प्रतिक्रिया और status.code/status.msg। यदि परियोजना मौजूद नहीं है, हटाई जा चुकी है या खाते की नहीं है, तो परियोजना न मिलने के संदेश के साथ API कोड 404 लौटता है। प्रमाणीकरण और स्रोत आईपी संबंधी प्रतिबंध भी लागू होते हैं। उदाहरण वास्तविक अनुरोध नहीं भेजते, और सफल प्रतिक्रिया इस बात का प्रमाण नहीं है कि किसी सेवा प्रदाता ने नंबर स्थानांतरण स्वीकार कर लिया है या पूरा कर दिया है।

प्रभाव और कार्यप्रणाली

यह मानक विवरण रूट है जिसका उपयोग मौजूदा पोर्टल का पोर्टिंग-ऑर्डर दृश्य करता है। पोर्टल अपने उपयोगकर्ता इंटरफ़ेस के लिए फ़ील्ड का मिलान करता है और ग्राहक को दिखाने के लिए उनका अपना चयन लागू करता है; यह न मानें कि मूल API प्रतिक्रिया पोर्टल के JSON या उसके प्रदर्शन के समान है। जिस विवरण हैंडलर की समीक्षा की गई है, वह परियोजना में बदलाव नहीं करता और सीधे सेवा प्रदाता को अनुरोध नहीं भेजता या कोई शुल्क नहीं लगाता।