संगठन, एप्लिकेशन और एनवायरनमेंट
संगठन आपकी टीम और बिलिंग रखता है; एप्लिकेशन वर्कफ़्लो और API-की रखते हैं, और हर एक या तो live होता है या sandbox। यह स्ट्रक्चर सही रखने से ज़्यादातर उलझाने वाला व्यवहार टल जाता है।
संगठन = आपकी टीम, आपका बिलिंग बैलेंस, आपका ऑडिट लॉग।
एप्लिकेशन = वर्कफ़्लो, API-की, webhook डेस्टिनेशन, रिटेंशन पॉलिसी - और
live या sandbox का एक मोड। "मैंने बदलाव किया पर कुछ हुआ ही नहीं" जैसी
ज़्यादातर समस्याएं ग़लत एप्लिकेशन में होने की वजह से होती हैं।
#दो लेवल
संगठन आपका अकाउंट है। इसमें ये शामिल हैं:
- आपकी टीम और उनके रोल
- आपका बिलिंग बैलेंस और इनवॉइस
- आपका ऑडिट लॉग
- आपके सारे एप्लिकेशन
एप्लिकेशन संगठन के अंदर एक वर्कस्पेस है। इसमें ये शामिल हैं:
- अपने ख़ुद के वर्कफ़्लो
- अपनी ख़ुद की API-की
- अपने ख़ुद के webhook डेस्टिनेशन
- अपनी ख़ुद की डेटा-रिटेंशन पॉलिसी
- एक मोड:
liveयाsandbox
कंसोल के ऊपर मौजूद ड्रॉपडाउन से एप्लिकेशन के बीच स्विच करें।
#यह दिखने से ज़्यादा क्यों मायने रखता है
लगभग हर "मैंने बदला और कुछ हुआ ही नहीं" वाली रिपोर्ट इसी स्ट्रक्चर पर आकर सुलझती है:
- आपने एप्लिकेशन A में कोई वर्कफ़्लो एडिट किया जबकि आपके सेशन एप्लिकेशन B के तहत चल रहे हैं।
- आपने एक एप्लिकेशन में webhook डेस्टिनेशन जोड़ा और किसी दूसरे से इवेंट की उम्मीद कर रहे थे।
- आप जिस रिसोर्स को एड्रेस कर रहे हैं उससे अलग किसी एप्लिकेशन की की से कॉल कर रहे हैं, और किसी ऐसी चीज़ के लिए 404 या 403 पा रहे हैं जो साफ़ तौर पर मौजूद है।
कुछ और डीबग करने से पहले एप्लिकेशन की पुष्टि करें। देखें API एरर और उनका मतलब।
#Live और sandbox अलग-अलग एप्लिकेशन हैं
किसी live एप्लिकेशन के अंदर कोई टेस्ट-मोड स्विच नहीं होता। मोड हर एप्लिकेशन के लिए चुना जाता है, इसलिए टेस्टिंग का मतलब है sandbox मोड में दूसरा एप्लिकेशन बनाना और उसकी की इस्तेमाल करना।
यही अलगाव पूरी बात है: टेस्ट ट्रैफ़िक और प्रोडक्शन डेटा कभी नहीं मिलते, और कोई sandbox की ग़लती से भी असली क्रेडिट ख़र्च नहीं कर सकती। देखें sandbox में टेस्टिंग।
एप्लिकेशन को ऐसे नाम दें कि उन्हें एक नज़र में कभी उलझाया न जा सके - acme-live
और acme-sandbox, "Application" और "Application (2)" से बेहतर हैं। कीज़ को भी
अपने सीक्रेट मैनेजर में मिलते-जुलते नामों से रखें, और किसी एक एनवायरनमेंट
वेरिएबल को कभी "जो भी की अभी चालू है" जैसा न बनने दें।
#आपके पास कितने एप्लिकेशन होने चाहिए?
कम से कम एक live और एक sandbox। इसके अलावा, जिस भी चीज़ को अपना अलग कॉन्फ़िगरेशन या अलगाव चाहिए, उसके हिसाब से बांटें:
- हर प्रोडक्ट के लिए, जब अलग-अलग प्रोडक्ट को अलग वर्कफ़्लो और अलग webhook एंडपॉइंट चाहिए हों।
- हर एनवायरनमेंट के लिए, अगर आप एक से ज़्यादा प्री-प्रोडक्शन एनवायरनमेंट चलाते हैं।
- हर ब्रांड के लिए, अगर आप अलग-अलग स्टाइलिंग वाले कई ब्रांड के तहत सत्यापन देते हैं।
- हर रिटेंशन पॉलिसी के लिए, क्योंकि रिटेंशन हर एप्लिकेशन के हिसाब से कॉन्फ़िगर होता है।
क्या चीज़ एप्लिकेशन के हिसाब से नहीं बंटती: आपका बैलेंस, जो संगठन-स्तर पर होता है। हर एप्लिकेशन उसी क्रेडिट में से ख़र्च करता है।
#और एप्लिकेशन बनाना
अतिरिक्त एप्लिकेशन कंसोल में बनाए जाते हैं। अगर यह विकल्प न दिखे, या आपको कंसोल के बजाय API के ज़रिए बनाना हो, तो यह अकाउंट-लेवल परमिशन का सवाल है और इसके इर्द-गिर्द रास्ता निकालने के बजाय सपोर्ट से पूछना बेहतर है - ख़ासकर दूसरे live एप्लिकेशन के लिए, जहां जवाब आपके प्लान पर निर्भर हो सकता है।
#कई संगठन
एक व्यक्ति का ईमेल एक समय में एक ही संगठन का होता है, और आपके संगठन के नीचे उप-संगठन या उप-खाते बनाने का कोई तरीका नहीं है। यदि आप अपने कई ग्राहकों को सेवा देते हैं, तो समर्थित संरचना है आपके एकल संगठन के भीतर प्रति ग्राहक एक एप्लिकेशन: हर एप्लिकेशन के अपने वर्कफ़्लो, ब्रांडिंग, API कुंजियाँ, परिणाम और उपयोग रिपोर्ट होती हैं, जो दूसरों से पूरी तरह अलग रहती हैं, जबकि बिलिंग आपके संगठन स्तर पर रहती है।
#Didit को पुनर्विक्रय करना
यदि आप Didit को अपने उत्पाद में बंडल करके अपने ग्राहकों से उसका शुल्क लेना चाहते हैं, तो वह रीसेलर मॉडल है। यह कैसे काम करता है, उन्हीं शर्तों में जो सहायता हर पूछने वाले को देती है:
- पूर्व-भुगतान क्रेडिट। न्यूनतम प्रारंभिक खरीद 5,000 USD, पूर्व-भुगतान, एक साल के समझौते पर। क्रेडिट कभी समाप्त नहीं होता, यह आपके संगठन स्तर पर रहता है और आपके द्वारा जोड़े गए सभी अंतिम ग्राहकों में खर्च होता है, और इसमें राशि के साथ बढ़ने वाली वॉल्यूम छूट शामिल है।
- डैशबोर्ड आप बनाते हैं। आप Didit के API को अपने फ्रंट एंड में एकीकृत करते हैं और आपके ग्राहक वहीं अपने वर्कफ़्लो, ब्रांडिंग और भूमिकाएँ प्रबंधित करते हैं। Didit Business Console की व्हाइट-लेबल प्रति प्रदान नहीं करता; आपके अंतिम उपयोगकर्ता जो सत्यापन स्क्रीन देखते हैं उन पर आपका ब्रांड हो सकता है (व्हाइट लेबल देखें), कंसोल पर नहीं।
- आपका मार्जिन आपका है। आपके ग्राहक जो मूल्य चुकाते हैं वह आप तय करते हैं। Didit आपसे समझौते की अवधि के लिए तय इकाई मूल्यों पर प्रति पूर्ण सुविधा शुल्क लेता है।
- यह स्थानीय-साझेदार कार्यक्रम नहीं है। Didit डेमो, ऑनबोर्डिंग और सहायता सीधे ग्राहकों के साथ करता है और वितरण या कार्यान्वयन साझेदार नहीं खोज रहा।
यदि आप पुनर्विक्रय संभालना नहीं चाहते, तो इसके बजाय रेफ़रल विकल्प का उपयोग करें: Business Console साइडबार में रेफ़रल खोलें, कार्यक्रम की शर्तें स्वीकार करें और अपना लिंक साझा करें। आप रेफ़र किए गए संगठन द्वारा किए गए हर नकद जमा पर 10% कमीशन, उनके पहले जमा से 36 महीनों तक कमाते हैं, जो Didit क्रेडिट के रूप में उपयोग किया जा सकता है या परिपक्व होने पर बैंक हस्तांतरण से भुगतान किया जा सकता है - बिना किसी डिलीवरी या सहायता दायित्व के। किसी भी विकल्प के लिए प्रतिबद्ध होने से पहले आप मुफ़्त टियर पर अपना एकीकरण बना और परख सकते हैं।
#किसी एप्लिकेशन को डिलीट करना
किसी एप्लिकेशन को डिलीट करने से उसके वर्कफ़्लो और कॉन्फ़िगरेशन हट जाते हैं। उसका सत्यापन डेटा एप्लिकेशन के जीवनचक्र के बजाय उस डेटा की रिटेंशन पॉलिसी और डिलीशन नियमों का पालन करता है - इसलिए अगर आपका मक़सद ग्राहक का डेटा मिटाना है, तो यह मान लेने के बजाय कि एप्लिकेशन हटाने से यह हो जाएगा, डेटा को साफ़ तौर पर डिलीट करें। देखें सेशन और निजी डेटा डिलीट करना।
#सब कुछ जवाबदेह है
हर API कॉल 365 दिनों के लिए ऑडिट लॉग में यह दर्ज करती है कि वह किस एप्लिकेशन की थी। यही चीज़ मल्टी-एप्लिकेशन स्ट्रक्चर को सिर्फ़ व्यवस्थित नहीं, बल्कि ऑडिट करने लायक बनाती है। देखें ऑडिट लॉग का इस्तेमाल।