--- title: रेट लिमिट description: प्रति-कॉन्ट्रैक्ट रेट लिमिट, Retry-After हेडर, और बजट के भीतर रहने के पैटर्न। canonical: https://developer.unico.io/hi/developers/start/rate-limits locale: hi generated_by: markdown-export --- - [/hi/](/hi/) - [शुरू करें](/hi/developers/start/) - रेट लिमिट **इस पेज पर# रेट लिमिट रेट लिमिट यह परिभाषित करता है कि कोई एप्लिकेशन किसी निर्दिष्ट समय अवधि के भीतर API को अधिकतम कितनी रिक्वेस्ट भेज सकता है। सेवाओं के समग्र स्वास्थ्य और विश्वसनीयता को बनाए रखने के लिए यह तंत्र महत्वपूर्ण है। ### हम रेट लिमिटिंग का इस्तेमाल क्यों करते हैं​ API stability and performance किसी एक क्लाइंट को अत्यधिक रिक्वेस्ट से सर्वर पर हावी होने से रोकता है। सभी क्लाइंट के लिए सुसंगत और अनुमानित रिस्पॉन्स समय सुनिश्चित करता है। बैकएंड सेवाओं को अप्रत्याशित ट्रैफ़िक स्पाइक से बचाता है। इंफ्रास्ट्रक्चर पर एक स्थिर और नियंत्रित लोड पैटर्न बनाए रखता है। Security ब्रूट फ़ोर्स जैसे हमले के प्रयासों के विरुद्ध सुरक्षा को मज़बूत करता है। डिस्ट्रिब्यूटेड डिनायल-ऑफ़-सर्विस (DDoS) के जोखिम को कम करता है। खराब ढंग से लागू किए गए इंटीग्रेशन से होने वाले प्रभाव को कम करता है। कॉम्प्रोमाइज़ हुए API क्रेडेंशियल से होने वाले संभावित नुकसान को सीमित करता है। Resource allocation सभी क्लाइंट के लिए API संसाधनों तक संतुलित पहुँच सुनिश्चित करता है। कुछ के दुरुपयोग को अन्य यूज़र के अनुभव को खराब करने से रोकता है। बिज़नेस मानदंड और ज़रूरतों के अनुसार ट्रैफ़िक को प्राथमिकता देने देता है। API के अधिक कुशल और टिकाऊ उपभोग के तरीकों को प्रोत्साहित करता है। ### रेट लिमिटिंग कैसे काम करती है​ हर API कॉल अनुमत requests-per-second लिमिट में गिनी जाती है। डिफ़ॉल्ट वैल्यू प्रति टेनेंट **10 RPS** है। लिमिट पार होने पर, API `HTTP 429 Too Many Requests` लौटाता है। Unico टीम से पुष्टि करेंसटीक लिमिट प्रति टेनेंट कॉन्फ़िगर की जाती हैं। हाई-थ्रूपुट इंटीग्रेशन के लिए साइज़िंग करने से पहले, अपने अकाउंट पर लागू लिमिट की पुष्टि करने के लिए Unico टीम से संपर्क करें। ### 429 त्रुटियों को हैंडल करना​ Request a rate limit increase अगर आपके ऑपरेशन में रिक्वेस्ट वॉल्यूम में वृद्धि होगी (अस्थायी या स्थायी रूप से), तो अपने एनवायरनमेंट के लिए रेट लिमिट बढ़ाने के लिए Unico टीम को सूचित करें। यह अनुरोध वॉल्यूम में वृद्धि होने से **पहले** किया जाना चाहिए ताकि आपका एप्लिकेशन निष्क्रिय न हो जाए। Review application behavior अकुशल API उपयोग पैटर्न की पहचान करने के लिए अपने कोड का ऑडिट करें। अनजाने लूप या रिडंडेंट API कॉल की जाँच करें। रिक्वेस्ट को बड़े बर्स्ट में भेजने के बजाय समय के साथ अधिक समान रूप से वितरित करें। Implement caching बार-बार एक्सेस किए जाने वाले डेटा को कैश करें जो शायद ही कभी बदलता है। OAuth2 एक्सेस टोकन का इस्तेमाल इसके पूरे 1-घंटे के TTL के लिए करें — हर रिक्वेस्ट पर `POST /oauth2/token` कॉल न करें। उपयुक्त कैश इनवैलिडेशन रणनीतियाँ लागू करें। Use webhooks instead of polling `GET /client/v1/process/\{id\}` को पोल करने के बजाय `PROCESS_STATE_FINISHED` के लिए [Webhooks and Events](/hi/developers/webhooks-and-events) सब्सक्राइब करें। भारी ट्रैफ़िक पर एक पोलिंग लूप GET-process बजट को आसानी से खत्म कर सकता है। ### लिमिट पर पहुँचने पर क्या होता है​ प्लेटफ़ॉर्म यह लौटाता है: ``` HTTP/1.1 429 Too Many RequestsRetry-After: 12 ``` HeaderMeaning`Retry-After`रीट्राई करने से पहले प्रतीक्षा करने के लिए सेकंड की संख्या। इसका पालन करें। अगर `Retry-After` मौजूद नहीं है, तो 60s पर सीमित एक्सपोनेंशियल बैकऑफ़ (1s, 2s, 4s, 8s, …) पर वापस जाएँ। ### कंकरेंसी संबंधी विचार​ रेट लिमिट प्रति मिनट रिक्वेस्ट को सीमित करते हैं, लेकिन प्लेटफ़ॉर्म में इंफ्रास्ट्रक्चर स्तर पर **कंकरेंसी कैप** भी हैं। भले ही आपके पास 100 रिक्वेस्ट/मिनट का बजट हो, सभी 100 को एक ही सेकंड में भेजना पूरे मिनट में फैलाने की तुलना में अस्वीकृत होने की अधिक संभावना रखता है। हाई-थ्रूपुट इंटीग्रेशन के लिए, बर्स्ट के बजाय एक स्थिर RPS को लक्ष्य बनाएँ। ### Magic Link वेबहुक डिलीवरी​ Trully के पास Webhook V2 के लिए अपना डिलीवरी कोटा है। वेबहुक सर्वर से **1 मिनट** के भीतर रिस्पॉन्स देने की अपेक्षा की जाती है; धीमे रिस्पॉन्स को छोड़ दिया जाता है (यूज़र की प्रोसेस प्रभावित नहीं होती)। सुसंगत प्रोसेसिंग के लिए, वेबहुक को तुरंत स्वीकार करें और इसे असिंक्रोनस रूप से प्रोसेस करें। ### आगे क्या​ [Authentication](/hi/developers/start/authentication) — टोकन कैशिंग रणनीति। [Webhooks and Events](/hi/developers/webhooks-and-events) — पोलिंग को पुश से बदलना। [Error codes > Retry policy](/hi/developers/start/error-codes#retry-policy) — कब (और कब नहीं) रीट्राई करना है। अंतिम अपडेट 8 अक्टू॰ 2026** को