उपयोगकर्ता, टीमें और भूमिकाएँ
Bird में लोगों का एक्सेस भूमिका-आधारित है: एक उपयोगकर्ता आपके वर्कस्पेस पर एक भूमिका रखता है, और हर भूमिका अनुमतियों का एक निश्चित सेट होती है। कुछ और कॉन्फ़िगर करने की ज़रूरत नहीं; सही भूमिका चुनें और अनुमतियाँ अपने आप लागू हो जाती हैं।
भूमिकाएँ यह तय करती हैं कि लोग डैशबोर्ड में क्या कर सकते हैं। सेवाएँ क्या कर सकती हैं, यह API key scopes द्वारा नियंत्रित होता है: वही अनुमति शब्दावली, जो भूमिका के बजाय प्रति key दी जाती है।
वर्कस्पेस भूमिकाएँ
जिन भूमिकाओं से आप रोज़ काम करते हैं, वे वर्कस्पेस पर होती हैं (देखें Workspace): admin, developer, और analyst। इन्हें डैशबोर्ड में Settings > Team के अंतर्गत प्रबंधित करें।
हर अनुमति एक {scope, level} जोड़ी है, जहाँ level या तो read या write होता है (write में read शामिल है)। एक भूमिका इन जोड़ियों का एक नामित, निश्चित सेट है:
| Scope | write का अर्थ | admin | developer | analyst |
|---|---|---|---|---|
| workspace | वर्कस्पेस सेटिंग्स संपादित करें (नाम, सूचनाएँ) | write | read | read |
| api_keys | API keys बनाएँ और रद्द करें | write | write | none |
| emails | ईमेल भेजें | write | write | read |
| email_management | सप्रेशन और ईमेल कॉन्फ़िगरेशन प्रबंधित करें | write | write | read |
| email_marketing | कॉन्टैक्ट्स, ऑडियंस और ब्रॉडकास्ट प्रबंधित करें | write | write | read |
| domains | सेंडिंग डोमेन जोड़ें, सत्यापित करें और हटाएँ | write | write | read |
| webhooks | Webhook endpoints कॉन्फ़िगर करें | write | write | read |
| sms | SMS भेजें | write | write | read |
| sms_management | SMS सेंडर, सप्रेशन और सेटिंग्स प्रबंधित करें | write | write | read |
| verify | सत्यापन कोड भेजें और जाँचें | write | write | read |
| verify_management | सत्यापन सेंडर और देश कॉन्फ़िगर करें | write | write | read |
| WhatsApp संदेश भेजें | write | read | read | |
| whatsapp_management | WhatsApp टेम्पलेट और सेटिंग्स प्रबंधित करें | write | write | read |
| assets | एसेट और फ़ोल्डर अपलोड करें, अपडेट करें और हटाएँ | write | write | read |
| compliance | रजिस्ट्रेशन आइडेंटिटी, सबमिशन और साक्ष्य प्रबंधित करें | write | write | read |
| lookup | फ़ोन नंबर, ईमेल पते और आइडेंटिटी मैच देखें | write | write | none |
| mailbox | मेलबॉक्स संदेश भेजें और उनका उत्तर दें | write | write | read |
| mailbox_management | मेलबॉक्स और रिसीव रूल बनाएँ, अपडेट करें और हटाएँ | write | write | read |
| realtime | ऐप्स बनाएँ और इवेंट पब्लिश करें | write | write | read |
| voice | लेग लॉग और आँकड़े देखें, और कॉल करें | write | write | read |
| voice_management | ट्रंक, गेटवे, नंबर, कॉलर ID और डेस्टिनेशन प्रबंधित करें | write | write | read |
| ip_pools | संगठन के IP पूल देखें (केवल पढ़ने के लिए) | read | read | read |
| members | वर्कस्पेस टीम और आमंत्रण प्रबंधित करें | write | read | read |
| analytics | रिपोर्ट और डिलीवरेबिलिटी एनालिटिक्स देखें | read | none | read |
| audit | ऑडिट लॉग देखें | read | none | read |
| request_logs | रिक्वेस्ट लॉग देखें (केवल पढ़ने के लिए) | read | read | read |
व्यवहार में, एक admin वर्कस्पेस चलाता है, जिसमें टीम और सेटिंग्स शामिल हैं। एक developer इंटीग्रेशन बना सकता है, डोमेन और webhooks प्रबंधित कर सकता है, और API keys बना सकता है। एक analyst के पास केवल पढ़ने का एक्सेस होता है।
दो पंक्तियाँ ध्यान से देखने लायक हैं। ip_pools admins के लिए भी केवल read-only है क्योंकि डेडिकेटेड IP खरीदने और पूल प्रबंधित करने के लिए संगठन-स्तरीय org:ip_pools:write scope चाहिए। WhatsApp अनुमतियाँ भी प्रबंधन को मैसेजिंग से अलग करती हैं। एक developer whatsapp_management:write से टेम्प्लेट और सेटिंग्स प्रबंधित कर सकता है, लेकिन whatsapp:read से केवल संदेश पढ़ सकता है; भेजना केवल admins तक सीमित रहता है। अन्य प्रोडक्ट उसी {scope, level} मॉडल का उपयोग करके scopes जोड़ते हैं।
किसी भी endpoint से 403 का मतलब है कि प्रमाणित प्रिंसिपल के पास उस endpoint के लिए ज़रूरी {scope, level} नहीं है। समाधान है भूमिका बदलना (व्यक्ति के लिए) या सही scopes वाली नई key बनाना (सेवा के लिए)।
संगठन भूमिकाएँ
आपके वर्कस्पेस के पीछे एक संगठन होता है जो बिलिंग और समग्र सदस्य सूची का स्वामी होता है। दो भूमिकाएँ उस स्तर को प्रबंधित करती हैं:
- owner: सब कुछ। संगठन और वर्कस्पेस संचालन में पूर्ण read और write एक्सेस। एक संगठन में कई owner हो सकते हैं (और होने चाहिए)। जिस व्यक्ति ने अकाउंट बनाया वह owner के रूप में शुरू होता है।
- billing_admin: बिलिंग और संगठन सेटिंग्स (org:billing:write, org:settings:write) तथा संगठन सदस्य सूची और वर्कस्पेस मेटाडेटा का read एक्सेस। वर्कस्पेस के अंदर के रिसोर्स का कोई एक्सेस नहीं।
ये रोज़मर्रा में शायद ही काम आती हैं: अधिकांश टीम सदस्यों को केवल वर्कस्पेस भूमिका चाहिए।
सदस्य और टीम
सदस्यता अंतर्निहित है: कोई उपयोगकर्ता आपके संगठन "in" है अगर उसके पास संगठन भूमिका या वर्कस्पेस भूमिका है। प्रबंधित करने के लिए कोई अलग सदस्यता रिकॉर्ड मौजूद नहीं है।
आप अपने वर्कस्पेस के लोगों को डैशबोर्ड में Settings > Team के अंतर्गत प्रबंधित करते हैं, जो वर्कस्पेस members scope द्वारा नियंत्रित है; एक वर्कस्पेस admin बिना किसी संगठन-स्तरीय भूमिका के यहाँ टीम प्रबंधित करता है। टीम प्रबंधन लोगों का काम है, इसलिए API keys में members scope नहीं हो सकता (देखें Authentication)।
किसी व्यक्ति की वर्कस्पेस एक्सेस हटाने से केवल वह रोल हटता है; उनकी कोई भी ऑर्गनाइज़ेशन रोल अपरिवर्तित रहती है। किसी को ऑर्गनाइज़ेशन से हटाने पर उनकी पूरी अकाउंट एक्सेस रद्द हो जाती है। उनके बनाए API keys काम करती रहती हैं क्योंकि हर key अपने क्रिएटर से स्वतंत्र रूप से वर्कस्पेस से जुड़ी होती है।
आमंत्रण
Settings > Team से किसी ईमेल एड्रेस को एक रोल के साथ इनवाइट करें, और Bird बाकी सब संभाल लेता है। बटन के पीछे एक स्मार्ट इनविटेशन है: एक ही फ़्लो उन सहकर्मियों को भी हैंडल करता है जो पहले से आपके ऑर्गनाइज़ेशन में हैं, और उन लोगों को भी जिन्होंने Bird के बारे में कभी नहीं सुना।
- पहले से संगठन सदस्य हैं: उन्हें दी गई भूमिका के साथ तुरंत वर्कस्पेस में जोड़ दिया जाता है। कोई ईमेल नहीं, कोई प्रतीक्षा नहीं; रिस्पॉन्स एक member ऑब्जेक्ट होता है।
- अभी तक सदस्य नहीं हैं: Bird एक आमंत्रण बनाता है, उन्हें एक साइनअप लिंक ईमेल करता है, और रिस्पॉन्स pending स्टेटस वाला एक invitation ऑब्जेक्ट होता है। लिंक 7 दिनों तक मान्य है; उसके बाद आमंत्रण समाप्त हो जाता है और आप उन्हें दोबारा आमंत्रित करते हैं।
रिस्पॉन्स का type फ़ील्ड (team_member या invitation) बताता है कि क्या हुआ। एक ही ईमेल के लिए दूसरा लंबित आमंत्रण डुप्लिकेट बनाने के बजाय 409 लौटाता है, और आप किसी भी समय उसी पेज से लंबित आमंत्रण वापस ले सकते हैं।
एक owner दूसरे owner या billing_admin को इनवाइट कर सकता है। उस इनविटेशन के लिए org:members:write ज़रूरी है, जो केवल owners के पास होता है।
सुरक्षा नियम
हर भूमिका परिवर्तन पर दो अपरिवर्तनीय नियम लागू होते हैं, चाहे कोई भी बदलाव करे:
- आखिरी owner अपरिवर्तनीय है। किसी संगठन के एकमात्र owner को पदावनत करना या हटाना 409 लौटाता है: एक संगठन कभी भी बिना owner के नहीं रह सकता। पहले दूसरे owner को प्रमोट करें।
- आप अपना खुद का एक्सेस नहीं बदल सकते। अपनी भूमिका बदलना या खुद को हटाना 403 लौटाता है। यह आकस्मिक सेल्फ-लॉकआउट और चुपचाप सेल्फ-प्रमोशन दोनों को रोकता है; बदलाव किसी अन्य admin या owner को करना होता है।
संदर्भ कैसे चुना जाता है
Member और team endpoints दो स्तरों पर मौजूद हैं, और कोई रिक्वेस्ट किस संगठन या वर्कस्पेस को लक्षित करती है, यह उसके प्रमाणीकरण के तरीके पर निर्भर करता है:
- Session auth (डैशबोर्ड, या आपके रूप में काम करने वाले टूल) प्रति रिक्वेस्ट संदर्भ प्रदान करता है: संगठन-स्कोप्ड endpoints पर X-Organization-Id, वर्कस्पेस-स्कोप्ड endpoints पर X-Workspace-Id।
- API keys अपना संदर्भ अंतर्निहित रूप से रखती हैं। एक key आपके वर्कस्पेस से संबंधित होती है, जो संगठन को भी निर्धारित करती है; किसी हेडर की ज़रूरत नहीं, और key के विपरीत कोई context हेडर malformed के रूप में अस्वीकृत हो जाता है (400)।
पूर्ण context-resolution मॉडल के लिए Workspace देखें।
अगले कदम
- Authentication & API keys: सेवाओं के लिए scopes, और keys कौन प्रबंधित कर सकता है
- Workspace: वह वर्कस्पेस जिससे ये भूमिकाएँ जुड़ी हैं
- Billing & usage: org-level बिलिंग भूमिकाएँ क्या प्रबंधित करती हैं
संबंधित संसाधन
इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।