Sign inGet Started

अनुरोध दर सीमाएँ

अनुरोध दर सीमाएँ यह तय करती हैं कि आपका संगठन एक समय विंडो में कितने अनुरोध कर सकता है। ट्रैफ़िक की गति नियंत्रित करने के लिए प्रतिक्रिया हेडर का उपयोग करें और अस्वीकृत अनुरोध से उबरने के लिए फिर से प्रयास विलंब का उपयोग करें।

सीमाएँ कैसे तय होती हैं

आपका संगठन प्रत्येक नीति के लिए एक क्षेत्रीय सीमा साझा करता है, अपनी सभी API कुंजियों और वर्कस्पेस में। एक और कुंजी बनाने से क्षमता नहीं बढ़ती। अलग-अलग संगठनों की सीमाएँ अलग होती हैं।
प्रत्येक अनुरोध एक ग्राहक नीति की खपत करता है। प्रोडक्ट नीतियों की क्षमता स्वतंत्र होती है: मैसेज स्थिति प्राप्त करना सामान्य रिसोर्स-रिट्रीवल सीमा की खपत नहीं करता, और ईमेल भेजना रिसोर्स-क्रिएशन सीमा की खपत नहीं करता।
लॉगिन, पासवर्ड रीसेट, और अन्य सुरक्षा-संवेदनशील ऑपरेशनों पर अतिरिक्त दुरुपयोग सुरक्षा लागू होती है। सप्लायर जाँच और कनेक्शन सीमाएँ भी आपकी प्लान की अनुरोध दर सीमाओं से स्वतंत्र रूप से अनुरोध अस्वीकार कर सकती हैं।

ग्रुप

सामान्य API ऑपरेशन इन नीतियों का उपयोग करते हैं:
नीतिऑपरेशन
api_getएक रिसोर्स प्राप्त करना
api_listकलेक्शन सूचीबद्ध या खोजना
api_createरिसोर्स बनाना
api_updateरिसोर्स अपडेट या अपसर्ट करना
api_deleteरिसोर्स हटाना
प्रोडक्ट ऑपरेशन सामान्य API नीति के स्थान पर एक नामित नीति का उपयोग करते हैं। उदाहरणों में email_send, email_batch, sms_send, whatsapp_send, lookup, और message_status_read शामिल हैं। बैच नीतियाँ सबमिशन अनुरोधों की गणना करती हैं; बैच की प्राप्तकर्ता संख्या अतिरिक्त नीति इकाइयों की खपत नहीं करती। बैच-आकार सीमाओं के लिए ईमेल बैच भेजना और SMS बैच भेजना देखें।
REST ईमेल और SMTP सबमिशन email_send क्षमता साझा करते हैं। एक SMTP DATA सबमिशन एक इकाई की खपत करता है; SMTP प्रमाणीकरण नहीं करता। यदि नीति सबमिशन अस्वीकार करती है, तो सर्वर फिर से प्रयास विलंब के साथ अस्थायी 452 4.3.1 लौटाता है और मैसेज स्वीकार नहीं करता। मैसेज को कतार में रखें और उस विलंब के बाद फिर से प्रयास करें।
ब्रॉडकास्ट बनाना api_create का उपयोग करता है; मौजूदा ब्रॉडकास्ट शुरू करना api_update का उपयोग करता है। इसके प्राप्तकर्ताओं को बैकग्राउंड डिलीवरी email_send की खपत नहीं करती। भेजने की अनुमतियाँ और डिलीवरी पेसिंग अलग नियंत्रण बने रहते हैं।
voice_call नीति इनबाउंड और आउटबाउंड कॉल प्रवेश को सीमित करती है। समाप्त नीति कॉल अस्वीकार करती है और calls_per_second_exceeded रिकॉर्ड करती है; कोई HTTP प्रतिक्रिया शामिल नहीं होती। अस्वीकृत कॉल देखें।

आपकी सीमा कैसे निर्धारित होती है

एक सक्रिय संगठन ओवरराइड आपकी प्रभावी दर निर्धारित करता है। ओवरराइड के बिना, आपकी सक्रिय प्लान का मान लागू होता है; यदि प्लान में उस नीति के लिए कोई मान नहीं है, तो डिफ़ॉल्ट लागू होता है। प्लान या ओवरराइड दर को बढ़ा या घटा सकता है। नीति की समय विंडो स्थिर रहती है।
अपना प्रभावी कोटा RateLimit-Policy प्रतिक्रिया हेडर से पढ़ें, जो उस कॉल पर लागू दर और विंडो के साथ नीति कुंजी का नाम बताता है। यदि आपको अतिरिक्त क्षमता चाहिए, तो नीति कुंजी और अपेक्षित ट्रैफ़िक के साथ सपोर्ट से संपर्क करें।

प्रतिक्रिया हेडर

अनुरोध दर सीमा मूल्यांकन IETF Structured Fields प्रारूप (RFC 9651) में दो हेडर प्रदान करते हैं:
कोड उदाहरण
RateLimit-Policy: "email_send";q=1000;w=60
RateLimit: "email_send";r=842;t=35
हेडरअर्थ
RateLimit-Policyलागू होने वाली नीति: q कोटा (अधिकतम इकाइयाँ) है और w सेकंड में विंडो है।
RateLimitआपकी वर्तमान स्थिति: r शेष इकाइयों की संख्या है और t विंडो रीसेट होने तक शेष सेकंड है।
उद्धृत स्ट्रिंग नीति का नाम बताती है। इस उदाहरण में, संगठन की प्रभावी email_send सीमा 60 सेकंड में 1,000 सबमिशन है, 842 शेष हैं और रीसेट में 35 सेकंड बाकी हैं।
429 प्राप्त होने से पहले अनुरोधों को धीमा करने के लिए r और t का उपयोग करें। t मान सेकंड में एक सापेक्ष विलंब है, Unix टाइमस्टैम्प नहीं।

जब आप सीमा तक पहुँच जाएँ

आपके इंटीग्रेशन को सामान्य संचालन के भाग के रूप में 429 प्रतिक्रियाओं को संभालना चाहिए। कम से कम, Retry-After का पालन करें और बैकऑफ़ के साथ फिर से प्रयास करें। जो क्लाइंट लाइव RateLimit हेडर (देखें प्रतिक्रिया हेडर) के आधार पर खुद की गति नियंत्रित करता है, वह सीमा तक पहुँचने से बचता है।
समाप्त ग्राहक नीति Retry-After सेकंड में 429 Too Many Requests और r=0 दिखाने वाले अनुरोध दर सीमा हेडर के साथ लौटती है। एक स्वतंत्र दुरुपयोग या सप्लायर सुरक्षा 429 लौटा सकती है, भले ही आपकी ग्राहक नीति में शेष क्षमता हो। फिर से प्रयास कब करना है यह तय करने के लिए Retry-After का पालन करें; यह नीति के t मान से भिन्न हो सकता है।
बॉडी मानक त्रुटि प्रतिक्रिया का उपयोग करती है:
कोड उदाहरण
{
  "error": {
    "type": "rate_limit_error",
    "code": "E01003",
    "name": "RateLimited",
    "message": "Too many requests. Please retry after the period indicated in the Retry-After header.",
    "doc_url": "https://bird.com/docs/api/errors/E01003",
    "request_id": "req_01ky7qavkff7qr88vadv6bv948"
  }
}
type: rate_limit_error पर ब्रांच करें। मानव-पठनीय मैसेज बदल सकता है। नीति कुंजी और फिर से प्रयास समय हेडर से पढ़ें:
async function sendWithBackoff(url, headers, payload, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await fetch(url, {
      method: "POST",
      headers,
      body: JSON.stringify(payload),
    });
    if (response.status !== 429) return response;
    const retryAfter = Number(response.headers.get("Retry-After") ?? 2 ** attempt);
    await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000));
  }
  throw new Error("rate limited after max retries");
}
उसी ऑपरेशन के फिर से प्रयास के लिए, उसकी आइडेम्पोटेंसी कुंजी का पुन: उपयोग करें। अनुरोध बॉडी को अपरिवर्तित रखें।
स्वचालित फिर से प्रयास और बैकऑफ़ व्यवहार के लिए SDK concepts देखें।

विफलता मोड

अनुरोध दर सीमक फ़ेल ओपन होता है: यदि Bird किसी सीमा का मूल्यांकन नहीं कर सकता, तो अनुरोध आगे बढ़ता है, न कि एक अनावश्यक अस्वीकृति प्राप्त करता है। अनुरोध दर सीमित करना सेवा क्षमता की सुरक्षा करता है। प्रमाणीकरण और प्राधिकरण सुरक्षा सीमाएँ बनी रहती हैं। Bird-साइड सीमक आउटेज 429 का कारण नहीं बनता।

अगले कदम

  • त्रुटियाँ: त्रुटि प्रतिक्रिया और त्रुटि प्रकारों पर ब्रांच कैसे करें
  • आइडेम्पोटेंसी: म्यूटेटिंग अनुरोधों के लिए सुरक्षित फिर से प्रयास
  • SDK concepts: स्वचालित फिर से प्रयास और बैकऑफ़ व्यवहार

संबंधित संसाधन

इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।

इम्प्लीमेंटेशन ब्रीफ़ पाएँ