नो-कोड पार्टनर API पोर्टल सेटअप: कुंजियाँ, स्कोप और ऑनबोर्डिंग

एक पार्टनर API पोर्टल क्या हल करता है (और क्यों यह उलझन में बदल सकता है)

एक पार्टनर API पोर्टल वह एक जगह है जहाँ बाहरी टीमें साइन इन कर सकती हैं, क्रेडेंशियल्स प्राप्त कर सकती हैं, और आपके API का उपयोग कैसे करना है यह समझ सकती हैं बिना अनवरत मेल‑मुलाकात के। इसे अपनी इंटीग्रेशन की फ्रंट‑डेस्क की तरह सोचें: पहुँच, दस्तावेज़ और बुनियादी अकाउंट कंट्रोल एक ही जगह।

यह आपके कंपनी के बाहर किसी भी ऐसे व्यक्ति के लिए है जिसे आपके सिस्टम्स तक भरोसेमंद पहुँच चाहिए: इंटीग्रेशन पार्टनर, रिसेलर, कॉन्ट्रेक्टर, एजेंसियाँ, या किसी ग्राहक की IT टीम जो कनेक्टर बना रही हो। अगर आप डेटा एक्सपोज़ कर रहे हैं, ऑर्डर बना रहे हैं, अकाउंट्स सिंक कर रहे हैं, या वर्कफ़्लो ट्रिगर कर रहे हैं, तो एक पोर्टल इन रिक्वेस्ट्स को एक अनुमानित प्रक्रिया में बदल देता है।

बिना पोर्टल के चीजें तेजी से गड़बड़ हो जाती हैं। एक सामान्य पैटर्न है “बस एक की शेयर कर दें” चैट या स्प्रेडशीट में। फिर कोई याद नहीं रखता कि कौन इसे उपयोग कर रहा है, यह क्या एक्सेस कर सकता है, या कब इसे रिवोक करना है जब कॉन्ट्रैक्ट खत्म हो जाए। अनुमतियाँ जनजातीय ज्ञान बन जाती हैं, कोटा गुस्से वाले फोन कॉल से लागू होते हैं, और हर नया पार्टनर कस्टम सेटअप बन जाता है।

एक नो‑कोड पार्टनर API पोर्टल इसका समाधान करता है: ऑनबोर्डिंग तेज़ बनाते हुए नियंत्रण वहीँ रखें जहाँ ज़रूरी है। लक्ष्य दिन‑एक पर एक परफेक्ट डेवलपर प्लेटफ़ॉर्म बनाना नहीं है — लक्ष्य है मैनुअल काम घटाना और जोखिम कम करना।

अधिकांश टीमें चार बेसिक चीज़ें पहले सुलझाकर सबसे ज़्यादा मूल्य प्राप्त करती हैं:

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

कम से शुरू करें, फिर समय के साथ कड़ाई बढ़ाएँ। आप एक सैंडबॉक्स वातावरण और दो स्कोप (read और write) से शुरुआत कर सकते हैं। पहले पार्टनर के लाइव होने के बाद आप जल्दी देखेंगे कि क्या और विवरण चाहिए: अलग‑अलग फीचर‑स्कोप, बेहतर ऑडिट लॉग, या कड़े लिमिट।

बिल्डिंग ब्लॉक्स: कुंजियाँ, स्कोप्स, कोटा और एनवायरनमेंट

एक नो‑कोड पार्टनर API पोर्टल तब चलाना आसान होता है जब आप मूविंग पार्ट्स को पहले नाम दे दें। ज्यादातर पोर्टल्स को कुछ ऑब्जेक्ट्स और उनके कनेक्शन नियमों के साथ समझाया जा सकता है।

एक सामान्य मॉडल कुछ ऐसा दिखता है:

• Partner: वह कंपनी (या टीम) जिसे आप अंदर आने दे रहे हैं।
• App (or client): उस पार्टनर का कोई विशिष्ट इंटीग्रेशन (एक पार्टनर के पास एक से अधिक हो सकते हैं)।
• API key (or token): वह सीक्रेट स्ट्रिंग जिसे ऐप आपके API को कॉल करने के लिए उपयोग करता है। एक की को एक ऐप से जोड़ा जाना चाहिए, किसी व्यक्ति से नहीं।
• Scope: उन कार्रवाइयों की सूची जिनके लिए की को अनुमति है।
• Quota (and rate limits): एक समय विंडो में ऐप कितना API उपयोग कर सकता है।

एक उपयोगी मानसिक मॉडल है Partner -> App -> API key, जिसमें scopes और quotas की (या ऐप) से जुड़ी हों। स्वामित्व स्पष्ट रहता है। अगर बाद में पार्टनर एक दूसरा इंटीग्रेशन बनाता है, उन्हें दूसरा ऐप और अलग‑अलग की मिलती है। आप केवल समस्या वाले हिस्से को सीमित या डिसेबल कर सकते हैं।

एनवायरनमेंट: सैंडबॉक्स बनाम प्रोडक्शन

अधिकांश टीमों को दो एनवायरनमेंट चाहिए। एक sandbox टेस्टिंग के लिए होता है, जिसमें नकली या सीमित डेटा होता है। Production में असली ग्राहक डेटा और असली प्रभाव होता है। पार्टनर दोनों में एक ही की साझा नहीं करना चाहिए।

क्या ऑडिट करें (ताकि सपोर्ट संभव हो)

एक साधारण पोर्टल भी कुछ बेसिक इवेंट्स रिकॉर्ड करे:

• की बनाई गई, रोटेट की गई, या रद्द की गई
• स्कोप जोड़े या हटाए गए
• कोटा में बदलाव
• की उपयोग (बुनियादी गिनती और एरर)

जब कोई पार्टनर कहे “आपका API डाउन है,” तो यह ऑडिट ट्रेल अक्सर 5 मिनट के फिक्स और एक हफ्ते के अनुमान के बीच फर्क होती है।

ऐसी अनुमति स्कोप डिज़ाइन करें जो समझने में आसान रहें

स्कोप एक सामान्य‑भाषा अनुमति लेबल है जो API की पर जुड़ा होता है। यह जवाब देता है: “यह पार्टनर क्या कर सकता है?” उदाहरण के लिए, orders:read वाली की ऑर्डर विवरण निकाल सकती है, जबकि refunds:create वाली की रिफंड शुरू कर सकती है। ये अनुमतियाँ डिफ़ॉल्ट रूप से साथ में बंडल न हों।

स्कोप्स को मानव‑अनुकूल और वास्तविक बिजनेस टास्क से जोड़कर रखें। पार्टनर और सपोर्ट टीम को एक की देखकर सेकंडों में समझ आ जाना चाहिए।

छोटा शुरू करें। कुल मिलाकर 5 से 10 स्कोप का लक्ष्य रखें, दर्जनों नहीं। बहुत ज़्यादा स्कोप भ्रम, गलत एक्सेस अनुरोध और “हमें एडमिन दे दो” दबाव पैदा करते हैं। आप बाद में नया स्कोप जोड़ सकते हैं, लेकिन एक बार पार्टनर उन पर निर्भर हो जाएं तो स्कोप लेना मुश्किल होता है।

स्कोप डिज़ाइन करने का व्यावहारिक तरीका है एंडपॉइंट्स को उस जॉब के हिसाब से ग्रुप करना जिसे वे सपोर्ट करते हैं, ना कि API की तकनीकी आकृति के हिसाब से। सामान्य समूह हैं: orders, customers, billing (invoices, payments, refunds), catalog (products, pricing), और webhooks (create, rotate secrets, pause)।

डिफ़ॉल्ट least privilege रखें। हर पार्टनर को सिर्फ वही दें जो उन्हें अभी चाहिए। इससे यदि कोई की लीक हो जाए तो नुकसान भी सीमित रहता है।

कुछ कार्रवाइयों के लिए अतिरिक्त रुकावट उचित है। रिफंड बनाना, payout विवरण बदलना, बड़े पैमाने पर ग्राहक डेटा एक्सपोर्ट करना, या वेबहुक्स प्रबंधित करना अक्सर “अनलॉक करने योग्य” अनुमतियों के रूप में बेहतर रहते हैं जिनके साथ आंतरिक चेकलिस्ट जुड़ी हो।

बिना ड्रामे के API कुंजियाँ जारी करना और रोटेट करना

किसी पार्टनर को API एक्सेस देने का सबसे शांत क्षण तब होता है जब आप जानते हों कि वे कौन हैं और उन्हें क्या करना है। कई टीमों के लिए, यह अप्रूवल और साइन्ड एग्रीमेंट के बाद होता है। छोटे प्रोग्राम्स में tight स्कोप के साथ self‑serve काम कर सकता है और उच्च‑जोखिम एक्सेस मैन्युअल समीक्षा के लिए रिज़र्व रखें।

की जारी करना बोरिंग होना चाहिए। पार्टनर को हमेशा एक स्पष्ट की नाम, यह क्या कर सकती है, और किस एनवायरनमेंट के लिए है दिखना चाहिए।

सीक्रेट्स को पासवर्ड की तरह संभालें। जहाँ संभव हो केवल हैश्ड वर्ज़न स्टोर करें, और निर्माण के समय पूरा सीक्रेट सिर्फ एक बार दिखाएँ। उसके बाद केवल एक छोटा की प्रिफिक्स दिखाएँ ताकि दोनों पक्ष लॉग्स को सही की से मिलाएँ।

रोटेशन वह जगह है जहाँ कई टीमें दर्द बनाती हैं, इसलिए इसे एक मानक फ्लो बनाएं:

1) Create a new key (same scopes, same partner)
2) Partner switches their integration to the new key
3) Confirm traffic is using the new key
4) Revoke the old key

रिवोकेशन और इमरजेंसी डिसेबल पहले‑कक्षा फीचर होने चाहिए। अगर किसी पार्टनर ने लीक की रिपोर्ट की, सपोर्ट को सेकंडों में की डिसेबल करने में सक्षम होना चाहिए, और कारण स्पष्ट रूप से लॉग होना चाहिए।

एक साधारण सुरक्षा कदम टिकटों को कम कर देता है: पार्टनरों को कई की बनाने दें (स्टेजिंग और प्रोड के लिए), पर प्रत्येक के लिए स्पष्ट लेबल और मालिक आवश्यक रखें।

ऐसे कोटा और रेट‑लिमिट जो पार्टनर सहन कर सकें

कोटा सिर्फ आपके सर्वरों की रक्षा नहीं करते — वे आपके ग्राहकों को स्लोडाउन से बचाते हैं और पार्टनर्स को अचानक बड़ी रिक्वेस्ट‑बाढ़ से बचाते हैं।

एक नीति तभी निष्पक्ष लगती है जब वह प्रत्याश्यपूर्ण हो। पार्टनर को एक बार पढ़कर पता होना चाहिए कि सामान्य उपयोग, ट्रैफ़िक स्पाइक, या बग के दौरान क्या होगा।

एक सरल स्टार्टर नीति दो सीमाएँ देती है: एक छोटे समय की रेट‑लिमिट और एक दैनिक कैप। प्रारम्भ में नंबर कॉन्सर्वेटिव रखें, फिर असली ट्रैफ़िक के आधार पर बढ़ाएँ।

उदाहरण:

• 60 requests per minute per API key
• 10,000 requests per day per API key

एनवायरनमेंट (sandbox vs production) के हिसाब से लिमिट अलग रखें, और महंगे एंडपॉइंट्स जैसे एक्सपोर्ट्स, सर्च, और फ़ाइल अपलोड्स के लिए कड़े लिमिट पर विचार करें।

जब कोटा हिट हो, तब अनुभव लिमिट जितना मायने रखता है उतना ही नियम। पार्टनर्स को अनुमान न लगाना पड़े। स्पष्ट एरर लौटाएँ जो बताता हो कि कौन‑सी लिमिट टकराई (per‑minute या daily), कब फिर से प्रयास करें, और जहाँ संभव हो Retry-After वैल्यू दें।

लिमिट बढ़ाने की प्रक्रिया को एक प्रोसेस बनाएं, हर बार नेगोशिएशन न बनाएं। शुरू में अपेक्षाएँ सेट करें: कौन अप्रूव करेगा, किस प्रकार का उपयोग साक्ष्य चाहिए, अप्रूव होने पर क्या बदलता है, और आप कब पुनरावलोकन करेंगे।

एक न्यूनतम ऑनबोर्डिंग फ्लो (स्टेप बाय स्टेप)

अच्छा ऑनबोर्डिंग फ्लो बैंक अकाउंट खोलने जैसा महसूस होना चाहिए: स्पष्ट सवाल, स्पष्ट सीमाएँ, और स्पष्ट अगला कदम। पहले वर्ज़न को छोटा और प्रत्याश्यनीय रखें, और बाद में केवल वही जोड़ें जो पार्टनर मांगें।

स्टेप 1–3: बेसिक्स जल्दी लें

कंपनी का नाम, एक तकनीकी संपर्क, उपयोग‑केस, और अपेक्षित मासिक वॉल्यूम (रिक्वेस्ट्स और डेटा साइज) इकट्ठा करें। एक फ्री‑टेक्स्ट फील्ड मददगार होता है: “30 दिनों में सफलता कैसी दिखेगी?”

अप्रूवल के बाद, पार्टनर को एक ऐप/क्लाइंट बनाने दें और पहले एक sandbox की जारी करें। की को एक नामित उद्देश्य से जोड़ें (उदाहरण: “Acme - Billing Sync”)। की के पास दो चीजें साफ़ दिखाएँ: यह किस एनवायरनमेंट के लिए है और यह कब बनाई गई थी।

स्टेप 4–6: स्कोप्स, पहली कॉल, फिर प्रोडक्शन

स्कोप चयन सरल रखें: अधिकतम 3 से 8 स्कोप, साधारण भाषा में वर्णित। फिर उन्हें सैंडबॉक्स में एक सンプल एंडपॉइंट (जैसे GET /status) और एक वास्तविक एंडपॉइंट से पहला टेस्ट कॉल करने के लिए गाइड करें।

सफल परीक्षण के बाद पार्टनर प्रोडक्शन एक्सेस का अनुरोध करे और एक अतिरिक्त प्रश्न का उत्तर दे: “आप किस तारीख को लाइव जा रहे हैं?” अप्रूवल के बाद प्रोडक्शन की जारी करें और सपोर्ट पाथ साफ़ दिखाएँ, जिसमें टिकट में क्या शामिल करें (रिक्वेस्ट ID और टाइमस्टैम्प) और कहाँ उपयोग और त्रुटियाँ देखें।

पोर्टल स्क्रीन जिन्हें शामिल करना चाहिए (छोटा रखें)

एक पार्टनर पोर्टल तब सबसे अच्छा काम करता है जब पार्टनर जल्दी चार सवालों का जवाब जान सकें: मेरी की क्या है? मैं क्या एक्सेस कर सकता हूँ? मैं कितना उपयोग कर सकता हूँ? क्या यह अभी काम कर रहा है?

पहले दिन के लिए स्क्रीन कुछ ही हों:

• Overview: स्थिति (pending, active, suspended, revoked) और वर्तमान एनवायरनमेंट।
• API Keys: की लेबल, बनाई गई तारीख, आख़िरी रोटेशन तारीख (निर्माण के बाद सीक्रेट कभी न दिखाएँ)।
• Access (Scopes): की क्या कर सकती है इसका साधारण भाषा सार।
• Usage and Quota: आज की कॉल्स, वर्तमान लिमिट्स, और जब वे हिट हों तो क्या होता है।
• Docs and Examples: एक क्विक‑स्टार्ट और कुछ कॉपी‑पेस्ट रिक्वेस्ट्स।

स्टेटस मॉडल संकरा रखें। “Pending” मौजूद होता है पर प्रोडक्शन कॉल नहीं कर सकता। “Active” का मतलब है प्रोडक्शन ऑन है। “Suspended” अस्थायी रोका हुआ है (बिलिंग या दुरुपयोग)। “Revoked” स्थायी है और सभी की अमान्य कर देता है।

Self‑serve एक्शन्स सपोर्ट लोड कम कर सकते हैं बिना नियंत्रण खोए। पार्टनरों को की रोटेट करने, अतिरिक्त स्कोप का अनुरोध करने, और ऊँचा कोटा माँगने दें, पर उन अनुरोधों को अप्रूवल कतार से गुजरने दें ताकि कुछ भी चुपके से न बदले।

सामान्य गलतियाँ जो सुरक्षा और सपोर्ट मुद्दे पैदा करती हैं

ज़्यादातर पार्टनर API पोर्टल साधारण कारणों से फेल होते हैं: शुरुआती शॉर्टकट जो तेज़ लगते हैं, लेकिन फिर अंतहीन सपोर्ट टिकट बन जाते हैं।

कई पार्टनरों (या कई ऐप्स) के बीच एक साझा API की क्लासिक गलती है। जब कोई इसका दुरुपयोग करता है, आप नहीं बता सकते कि किसने क्या किया, और आप एक पार्टनर का एक्सेस रिवोक नहीं कर सकते बिना सबको तोड़े। अलग‑अलग पार्टनरों के लिए अलग‑अलग की का प्रयोग करें, और आदर्शतः प्रति ऐप अलग की रखें।

स्कोप्स भी जल्दी गलत हो सकते हैं। एक “full_access” स्कोप आसान लग सकता है, पर यह आपको हर इंटीग्रेशन पर बराबर भरोसा करने पर मजबूर करता है और पार्टनर्स नर्वस हो जाते हैं। स्कोप्स को क्रियाओं (read, write, admin) के आधार पर और विशिष्ट संसाधनों से जोड़कर रखें।

गलती से प्रोडक्शन में टेस्टिंग

सैंडबॉक्स छोड़ना दो तरह का दर्द पैदा करता है: सुरक्षा जोखिम और गड़बड़ डेटा। पार्टनर किनारे‑केस टेस्ट करेंगे। अगर उनके पास केवल प्रोडक्शन तक पहुँच है, तो आप फेक ग्राहक, टूटे वर्कफ़्लो और सफ़ाई अनुरोध पाएँगे।

एक सरल नियम मदद करता है: सैंडबॉक्स की कभी भी प्रोडक्शन डेटा तक पहुँच नहीं सकती, और प्रोडक्शन की सैंडबॉक्स तक नहीं।

ऐसे कोटा जो यादृच्छिक फेल की तरह लगें

रेट‑लिमिट ठीक है, पर अस्पष्ट त्रुटियाँ बार‑बार रीट्राई और अधिक लोड पैदा करती हैं। हर लिमिट फ़ेलरी का उत्तर वही सवालों को दे: क्या हुआ, कब रीट्राई करें, वर्तमान उपयोग कहाँ देखें, ऊँचा लिमिट कैसे माँगे, और अगर कुछ गलत दिखे तो किससे संपर्क करें।

दिन‑एक से की रोटेशन की योजना बनाएं। लंबे समय तक चलने वाली कुंजियाँ स्क्रीनशॉट, लॉग या पुराने लैपटॉप्स से लीक हो जाती हैं। रोटेशन नियमित होना चाहिए, संकट नहीं।

पहला पार्टनर आमंत्रित करने से पहले त्वरित चेकलिस्ट

पहला इनवाइट भेजने से पहले पार्टनर के नजरिए से अन्तिम पास करें। छोटे चेक दो सामान्य नतीजों को रोकते हैं: अधिक‑अनुमति और भ्रमित करने वाला एक्सेस।

• पार्टनर कौन है रिकॉर्ड करें (कानूनी इकाई, तकनीकी संपर्क, और पहचान कैसे पुष्टि हुई)।
• UI और डॉक में सैंडबॉक्स स्पष्ट रखें, और सुरक्षित टेस्टिंग आसान बनाएं।
• प्रोडक्शन एक्सेस एक अलग निर्णय और स्पष्ट अप्रूवल स्टेप होना चाहिए।
• स्कोप्स ज़ोर से पढ़ें — अगर कोई स्कोप व्यापक लगे (“full access”) या अस्पष्ट लगे (“general”), तो उसे विभाजित या पुनः नामित करें।
• कोटा तय करें और फ़ेल पाथ (एरर रिस्पॉन्स, रीट्राई टाइमिंग, सपोर्ट दृश्यता) का अभ्यास करें।

एक व्यावहारिक टेस्ट करें: एक नकली पार्टनर अकाउंट बनाएं और पूरा फ्लो एंड‑टू‑एंड चलाएँ। फिर “break glass” एक्शन्स कम से कम एक बार टेस्ट करें: की रोटेट करें, पुरानी रद्द करें, और पुष्टि करें कि पार्टनर तुरंत ब्लॉक है।

उदाहरण: एक वास्तविक पार्टनर को एक घंटे से भी कम में ऑनबोर्ड करना

मिड‑साइज़ लॉजिस्टिक्स पार्टनर, NorthShip, को दो चीज़ों की जरूरत है: उनके डिस्पैच डैशबोर्ड के लिए read‑only shipment status और एक webhook ताकि उन्हें शिपमेंट बदलते ही सूचित किया जा सके।

स्कोप सेट छोटा और पठनीय रखें, उदाहरण के लिए:

• shipments:read (get shipment details and status)
• shipments:events:read (get latest tracking events)
• webhooks:manage (create, update, and disable their webhook endpoint)
• partner:profile:read (view partner account info for debugging)

कोटा के लिए शुरुआती अनुमान रखें जो आपको सुरक्षा दें बिना सामान्य उपयोग को दंडित किए। पहले सप्ताह में आप 60 requests per minute और 50,000 requests per day रख सकते हैं, और webhook रजिस्ट्रेशन्स के लिए अलग कैप रखें ताकि आकस्मिक लूप रोक सके।

एक सप्ताह बाद वास्तविक डेटा के आधार पर समायोजित करें। अगर उनका औसत 8 requests per minute है और शिफ्ट‑चेंज पर छोटा‑सा स्पाइक आता है, तो प्रति‑मिनट लिमिट बढ़ाएँ पर दैनिक कैप रखें। अगर आप लगातार polling देखते हैं, तो उन्हें caching और वेबहुक्स की ओर धकेलें बजाय केवल लिमिट बढ़ाने के।

एक वास्तविक समस्या यह है कि दिन 2 पर रेट लिमिट हिट हो रही है क्योंकि डैशबोर्ड हर 2 सेकंड पर हर डिस्पैचर के लिए पोल कर रहा है। आपके लॉग्स में बहुत से 429 मिल रहे हैं। समाधान: उन्हें 15–30 सेकंड के लिए रिज़ल्ट कैश करने और परिवर्तन के लिए वेबहुक्स पर भरोसा करने के लिए कहें। ट्रैफ़िक स्थिर होने पर प्रति‑मिनट लिमिट हल्का‑सा बढ़ाएँ और मॉनिटर करना जारी रखें।

अगले कदम: बनाएं, एक पार्टनर से टेस्ट करें, फिर बढ़ाएँ

पहले वर्ज़न को पायलट की तरहTreat करें। एक छोटा पोर्टल जो बेसिक्स साफ़ तरीके से संभाले बेहतर है बनाम फीचर‑भारी पोर्टल जो भ्रम पैदा करे।

सबसे छोटे स्क्रीन और नियमों के साथ शुरू करें जो एक पार्टनर को एंड‑टू‑एंड सफल होने दें: एक्सेस अनुरोध करें, अप्रूव हों, की प्राप्त करें, और पहली सफल API कॉल करें। बाकी सब कुछ तभी जगह बनाए जब वह टिकट में आने वाली समस्या का समाधान करे।

एक प्रबंधनीय बिल्ड ऑर्डर सामान्यतः ऐसा दिखता है:

• पार्टनर, ऐप्स, API की, स्कोप्स, और स्टेटस (requested, approved, suspended) मोडल करें।
• एक अप्रूवल स्टेप जोड़ें जिसमें स्पष्ट मालिक और मानदंड हों।
• की जारी करने और रोटेशन को स्वचालित करें, और हर बदलाव लॉग करें (किसने, कब, क्यों)।
• “मुझे अधिक एक्सेस चाहिए” स्थितियों के लिए स्कोप‑रिक्वेस्ट फ्लो जोड़ें।
• वास्तविक उपयोग पैटर्न दिखने पर कोटा जोड़ें।

यदि आप बिना कोड के बना रहे हैं, तो AppMaster मदद कर सकता है: आप डेटा मॉडल कर सकते हैं, आंतरिक और पार्टनर‑फेसिंग UI बना सकते हैं, और विज़ुअल टूल्स से की और स्कोप नियम लागू कर सकते हैं। अगर आप बाद में सेल्फ‑होस्ट रखना चाहते हैं, तो AppMaster (appmaster.io) जनरेट किए गए स्रोत कोड को एक्सपोर्ट भी कर सकता है जब आपको गहरी कस्टमाइज़ेशन चाहिए।