Sign inGet Started

Authentication और API keys

Bird API को भेजा गया हर प्रोग्रामैटिक अनुरोध एक API key से authenticate होता है, जो bearer token के रूप में पास की जाती है। Keys एक वर्कस्पेस से जुड़ी होती हैं, ऐसी permissions रखती हैं जिन्हें आप बदल सकते हैं, और पूरी तरह केवल एक बार दिखाई जाती हैं।
सर्विस क्रेडेंशियल्स और डेलिगेटेड एक्सेस के बीच अंतर के लिए देखें API keys और OAuth tokens।

अनुरोध कैसे authenticate होते हैं

हर अनुरोध पर Authorization हेडर में अपनी key पास करें। SDKs और CLI key एक बार लेते हैं और हेडर आपके लिए सेट कर देते हैं:
import { BirdClient } from "@messagebird/sdk";

const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });

await bird.email.send({
  from: "hello@yourdomain.com",
  to: ["delivered@messagebird.dev"],
  subject: "Hi",
  text: "Hello.",
});
Key prefix में region बताता है कि किस host को कॉल करना है: bk_us1_... keys https://us1.platform.bird.com पर जाती हैं, bk_eu1_... keys https://eu1.platform.bird.com पर। आधिकारिक Bird SDKs और CLI key से region पढ़कर आपके लिए host चुन लेते हैं। गलत regional host पर भेजी गई key 421 (type misdirected_error) लौटाती है; देखें Regions।
गायब या अमान्य key 401 लौटाती है। एक वैध key जिसमें endpoint के लिए ज़रूरी permission नहीं है, 403 लौटाती है। हेडर semantics और त्रुटि प्रतिक्रियाएँ authentication reference में हैं।

Key की संरचना

कोड उदाहरण
bk_us1_Ab3xKq9mP2wR5tY8uI1oL4n3A3aww
└┬┘└┬┘ └──────────┬──────────┘└─┬──┘
 │  │          payload      checksum
 │  └ region (routes the request)
 └ Bird key prefix
  • Prefix: bk_{region}_ क्रेडेंशियल का प्रकार और उसका region बताता है। यह निश्चित, विशिष्ट prefix ही है जो secret scanners को कोड में Bird key पहचानने देता है, और region सेगमेंट आपके अनुरोध को सही host पर रूट करता है।
  • Payload: 136 बिट की entropy वाले 23 रैंडम कैरेक्टर।
  • Checksum: अंतिम 6 कैरेक्टर बाकी key का checksum हैं, ताकि कोई SDK या API गलत टाइप की गई या कटी हुई key को lookup से पहले ही तुरंत अस्वीकार कर सके।
पूरी key केवल एक बार लौटाई जाती है, उस response में जो इसे बनाता है। आप बाद में plaintext प्राप्त नहीं कर सकते। बाद के responses पहले 15 कैरेक्टर key_prefix के रूप में शामिल करते हैं, उदाहरण के लिए bk_us1_Ab3xKq9m। इनमें एक स्थिर 12-कैरेक्टर fingerprint भी होता है जिससे आप key को लॉग्स और सपोर्ट वार्तालापों में मिला सकें बिना उसका मान उजागर किए।
अगर आप कोई key खो देते हैं, तो नया secret पाने के लिए इसे rotate करें, या इसे revoke करें और एक नई बनाएँ।

Key बनाना

Dashboard में Platform tools > API keys के अंतर्गत keys बनाएँ। Key एक नाम, एक या अधिक scopes, और एक वैकल्पिक expiry के साथ बनाई जाती है। इसे बनाने वाला response ही एकमात्र response है जो कभी token फ़ील्ड (पूरी key) रखता है: इसे तुरंत अपने secret manager में स्टोर करें।
आप ब्राउज़र के बिना भी bird api-keys create से एक बना सकते हैं। Key जारी करने के लिए api_keys:write scope चाहिए, जो read-only login baseline में शामिल नहीं होता, इसलिए साइन इन करते समय इसे अनुरोध करें:
कोड उदाहरण
bird auth login --scope api_keys:write
bird api-keys create --body-file - <<'JSON'
{
  "name": "Email operations production key",
  "scopes": [{ "scope": "emails", "level": "write" }]
}
JSON
संपादन के लिए एक पूरा body प्रिंट करने के लिए bird api-keys create --example चलाएँ।
Scopes एकमात्र चीज़ हैं जो कोई key स्वयं को grant नहीं कर सकती: api_keys:write API keys के लिए उपलब्ध नहीं है, इसलिए कोई key कभी दूसरी key जारी नहीं कर सकती। Issuance आपके रूप में चलता है, एक dashboard session या CLI या MCP grant पर।
Bird dashboard में API Keys पेज, जिसमें keys उनके masked prefix, scopes, और अंतिम उपयोग समय के साथ सूचीबद्ध हैं
Key बनाने के बाद आप उसे प्रबंधित कर सकते हैं:
  • Scopes संपादन योग्य हैं। संपादन permission set को बदल देता है और वही secret रखता है। आप वे scopes grant कर सकते हैं जो आपके अपने अकाउंट में हैं। अगर key ऐसी permission को सपोर्ट करने से पहले बनाई गई थी जैसे voice, तो वह permission जोड़ने के लिए इसे rotate करें। Revoked keys और rotation द्वारा पहले से बदली गई keys को संपादित नहीं किया जा सकता।
  • Expiry निश्चित है। expires_at तब सेट करें जब key को किसी ज्ञात समय पर काम करना बंद करना हो (किसी ठेकेदार का कार्यकाल, माइग्रेशन विंडो)। उस क्षण के बाद key 401 लौटाती है; बिना expiry वाली key revoke होने तक काम करती रहती है।
  • Key प्रबंधन लोगों के पास रहता है। Keys बनाने, संपादित करने और revoke करने के लिए api_keys:write permission चाहिए, जो workspace admin और developer roles के पास होती है (देखें Users, teams & roles) और किसी API key को कभी grant नहीं की जा सकती। लीक हुई key और keys नहीं बना सकती।
API keys पेज हर key को उसके key_prefix, scopes, और last_used_on तिथि (दिन की सटीकता) के साथ सूचीबद्ध करता है, ताकि आप पुरानी keys एक नज़र में पहचान सकें। Revoked keys सूची से बाहर रहती हैं जब तक आप उन्हें दिखाना न चुनें।

Scopes और levels

Key पर प्रत्येक scope एक {scope, level} जोड़ी है, जहाँ level read या write होता है (write में read शामिल है)। API keys ये scopes रखती हैं:
Scopereadwrite
emailsभेजे गए संदेश और डिलीवरी स्थिति पढ़ेंईमेल भेजें
email_managementsuppressions, ईमेल कॉन्फ़िगरेशन, और टेम्प्लेट पढ़ेंsuppressions, ईमेल कॉन्फ़िगरेशन, और टेम्प्लेट प्रबंधित करें
email_marketingcontacts, audiences, और broadcasts पढ़ेंcontacts, audiences, और broadcasts प्रबंधित करें
domainssending domains और उनके DNS records पढ़ेंsending domains जोड़ें, verify करें, और प्रबंधित करें
smsभेजे गए SMS और डिलीवरी स्थिति पढ़ेंSMS भेजें
sms_managementsenders, registrations, suppressions, keyword replies, destinations, और templates पढ़ेंsenders, registrations, suppressions, keyword replies, destinations, और templates प्रबंधित करें
whatsappभेजे गए WhatsApp संदेश और स्थिति पढ़ेंWhatsApp संदेश भेजें
whatsapp_managementWhatsApp टेम्प्लेट और सेटिंग्स पढ़ेंWhatsApp टेम्प्लेट और सेटिंग्स प्रबंधित करें
verifyसत्यापन स्थिति पढ़ेंसत्यापन कोड भेजें और जाँचें
realtimeRealtime apps, channels, और channel members पढ़ेंapps बनाएँ और events publish करें
voiceleg logs और call statistics पढ़ेंSIP calls authenticate करें और session credentials बनाएँ
voice_managementtrunks, gateways, numbers, caller IDs, और destinations पढ़ेंtrunks, gateways, numbers, caller IDs, और destinations प्रबंधित करें
mailboxmailboxes, threads, और messages पढ़ेंmailbox messages भेजें और उनका उत्तर दें
mailbox_managementreceive rules और mailbox कॉन्फ़िगरेशन पढ़ेंmailboxes और receive rules बनाएँ, अपडेट करें, और हटाएँ
assetsassets और folders पढ़ेंassets और folders अपलोड करें, अपडेट करें, और हटाएँ
workspaceवर्कस्पेस का नाम, organization ID, और सेटिंग्स पढ़ेंउपलब्ध नहीं
webhookswebhook subscriptions और उनके delivery प्रयास पढ़ेंwebhook बनाएँ, अपडेट करें, हटाएँ, टेस्ट करें, replay करें, और उसका secret rotate करें
lookupउपलब्ध नहींफ़ोन नंबर, ईमेल पते, और identity matches लुकअप करें
वर्कस्पेस सेटिंग्स बदलना, सदस्य प्रबंधित करना, keys जारी करना, और IP pools प्रबंधित करना जानबूझकर API keys को grant नहीं किया जा सकता, ताकि ये key के बजाय व्यक्ति के रूप में चलें: dashboard के माध्यम से, या CLI या MCP server पर ऐसे grant के माध्यम से जिसमें scope हो। सबसे संकीर्ण set grant करें जो काम करे: जो key केवल ईमेल भेजती है, उसे केवल emails:write रखनी चाहिए और कुछ नहीं।
lookup में कोई read-level operations नहीं हैं: हर lookup endpoint, जिसमें किसी मौजूदा result को fetch करना भी शामिल है, write की आवश्यकता होती है।

Key revoke करना

Platform tools > API keys के अंतर्गत key की row से उसे revoke करें। Revocation स्थायी है: revoked key को पुनः सक्रिय नहीं किया जा सकता, और उसका रिकॉर्ड revoked_at सेट के साथ audit के लिए संरक्षित रहता है।
Revocation तेज़ी से प्रसारित होता है लेकिन तुरंत नहीं। Key validation एक अल्पकालिक cache से गुज़रती है, इसलिए हाल ही में revoke की गई key कुछ सेकंड (अधिकतम पाँच) तक काम कर सकती है, इसके बाद उसके साथ हर अनुरोध 401 लौटाता है।

Key rotate करना

Rotation आपकी मौजूदा key का replacement जारी करता है और उसका token उस response में एक बार लौटाता है। Replacement स्रोत key का नाम, scopes, और source IP restrictions रखता है। यह बिना expiry के शुरू होता है। Platform tools > API keys के अंतर्गत key की row से rotate करें, या ब्राउज़र के बिना bird api-keys rotate और api_keys_rotate MCP tool से:
कोड उदाहरण
bird auth login --scope api_keys:write
bird api-keys rotate key_01hqz8kp3v9x2m --yes
पिछली key एक grace period तक काम करती रहती है, डिफ़ॉल्ट रूप से 24 घंटे, ताकि आप पुरानी key बंद होने से पहले नया token deploy कर सकें। पिछली key को तुरंत revoke करने के लिए grace_period: 0 (CLI पर --grace-period 0) पास करें, जो लीक हुई key के लिए उचित है: कोई overlap नहीं होता, और उसे ले जाने वाला हर अनुरोध विफल होने लगता है। जो key grace period से पहले expire होने के लिए पहले से सेट है, वह अपनी expiry रखती है, क्योंकि rotation कभी key की life नहीं बढ़ाता।
कुंजी रोटेशन को स्वचालित करने से पहले दो सीमाएँ ध्यान में रखें। रोटेशन कभी भी समाप्ति तिथि को आगे नहीं ले जाता, इसलिए किसी निश्चित समय पर समाप्त हुई कुंजी का प्रतिस्थापन रद्द किए जाने तक चलता रहता है; जब समाप्ति तिथि महत्वपूर्ण हो तो create के साथ फिर से जारी करें। और एक कुंजी को केवल एक बार रोटेट किया जा सकता है: उसी कुंजी का दूसरा रोटेशन 409 लौटाता है, इसलिए Idempotency-Key भेजें ताकि फिर से प्रयास करने पर मूल प्रतिक्रिया दोबारा मिल जाए। इसके बिना, जिस रोटेशन का जवाब आपको कभी नहीं मिला, उसने एक सक्रिय कुंजी बना दी है जिसका टोकन आप वापस नहीं पढ़ सकते।
दो keys को मैन्युअल रूप से overlap करना तब भी सुरक्षित रास्ता है जब आप यह अनुमान नहीं लगा सकते कि switchover में कितना समय लगेगा, क्योंकि grace period rotate करते समय निश्चित हो जाता है और बाद में बढ़ाया नहीं जा सकता:
  1. समान scopes के साथ एक नई key बनाएँ।
  2. नई key को अपनी सेवाओं में deploy करें।
  3. ट्रैफ़िक स्थानांतरित होने तक पुरानी key का last_used_on देखें।
  4. पुरानी key revoke करें।

Keys वर्कस्पेस की होती हैं

एक API key आपके वर्कस्पेस से बंधी होती है और उस वर्कस्पेस के अधिकार से authenticate करती है। बनाने वाले की व्यक्तिगत permissions इसे प्रभावित नहीं करतीं। इसके दो व्यावहारिक परिणाम हैं:
  • Keys कर्मचारी के जाने पर भी चलती रहती हैं। जब कोई कर्मचारी जाता है और उसका user account हटा दिया जाता है, तो उसने बनाई हुई keys काम करती रहती हैं। "create" क्लिक करने वाला व्यक्ति कंपनी छोड़ गया, इस कारण आपका कभी production outage नहीं होता। (उनका जाना फिर भी उन keys को rotate करने का एक अच्छा संकेत है जिन तक उनकी पहुँच थी।)
  • Key की पहुँच वर्कस्पेस पर रुक जाती है। यह कभी organization-level operations नहीं कर सकती: billing, org members, org settings।
चूँकि key वर्कस्पेस से जुड़ी होती है, key वाले अनुरोधों को किसी अतिरिक्त context की ज़रूरत नहीं; देखें Workspace कि वर्कस्पेस और उसके ऊपर का organization आपकी पहुँच को कैसे बाँटते हैं।

डेलिगेटेड पथ: CLI और MCP server के लिए OAuth tokens

API keys सेवाओं के लिए हैं। Bird CLI और Bird MCP server व्यक्ति के साइन इन करने पर OAuth का उपयोग करते हैं। आप ब्राउज़र से लॉग इन करते हैं, वर्कस्पेस चुनते हैं, और अपनी permissions का एक subset grant करते हैं। फिर tool एक अल्पकालिक bt_{region}_... user token प्राप्त करता है।
प्रत्येक token आपकी permissions तक सीमित होता है। आप Profile > Connected apps के अंतर्गत प्रत्येक tool का एक्सेस revoke कर सकते हैं। Tools ये tokens आपके लिए प्रबंधित करते हैं, इसलिए इन्हें कॉपी न करें या secret manager में स्टोर न करें। सर्वर वर्कलोड के लिए API keys का उपयोग करें।

अगले कदम

  • Authentication reference: अनुरोध हेडर semantics और त्रुटि प्रतिक्रियाएँ
  • Regions: regional hosts और routing
  • Users, teams & roles: keys कौन प्रबंधित कर सकता है
  • Workspace: वह वर्कस्पेस जिससे key बंधी होती है