---
title: Rate limits
description: Per-contract rate limits, Retry-After header और budget के भीतर रहने के patterns।
canonical: https://developer.unico.io/hi/dual-api/developers/api-reference/rate-limits
locale: hi
generated_by: markdown-export
---

- [/hi/](/hi/)
- [API संदर्भ](/hi/dual-api/developers/api-reference/)
- Rate limits

**इस पेज पर# Rate limits

Rate limit एक निर्दिष्ट समय अवधि में किसी application द्वारा API को किए जा सकने वाले अनुरोधों की अधिकतम संख्या को परिभाषित करता है। यह mechanism services के समग्र स्वास्थ्य और विश्वसनीयता बनाए रखने के लिए महत्वपूर्ण है।
### हम rate limiting का उपयोग क्यों करते हैं​

API stability and performance

एक client को अत्यधिक अनुरोधों के साथ servers को overwhelm करने से रोकता है।
सभी clients के लिए consistent और predictable response times सुनिश्चित करता है।
Backend services को अप्रत्याशित traffic spikes से बचाता है।
Infrastructure पर stable और controlled load pattern बनाए रखता है।

Security

Brute force जैसे हमले के प्रयासों के खिलाफ रक्षा को मजबूत करता है।
Distributed denial-of-service (DDoS) के जोखिम को कम करता है।
खराब ढंग से implemented integrations के कारण होने वाले प्रभाव को कम करता है।
Compromised API credentials के परिणामस्वरूप होने वाले संभावित नुकसान को सीमित करता है।

Resource allocation

सभी clients के लिए API resources तक संतुलित पहुँच सुनिश्चित करता है।
कुछ द्वारा दुरुपयोग को अन्य उपयोगकर्ताओं के अनुभव को ख़राब करने से रोकता है।
व्यावसायिक मानदंडों और ज़रूरतों के अनुसार traffic को प्राथमिकता देने की अनुमति देता है।
अधिक कुशल और sustainable API उपभोग प्रथाओं को प्रोत्साहित करता है।

### Rate limiting कैसे काम करता है​

प्रत्येक API call अनुमत requests-per-second limit की ओर count होती है। डिफ़ॉल्ट मान **10 RPS** प्रति tenant है। Limit से अधिक होने पर, API `HTTP 429 Too Many Requests` लौटाती है।
अपनी Onboarding team से पुष्टि करेंExact limits tenant के अनुसार configure की जाती हैं। High-throughput integrations के लिए sizing करने से पहले अपनी Onboarding team से संपर्क करके अपने account पर लागू limits की पुष्टि करें।
### 429 त्रुटियाँ संभालना​

Rate limit increase का अनुरोध करें
यदि आपके operation में request volume में वृद्धि होगी (अस्थायी या स्थायी), तो Unico team को अपने वातावरण के लिए rate limit बढ़ाने के लिए सूचित करें। यह अनुरोध volume वास्तव में बढ़ने से **पहले** किया जाना चाहिए ताकि आपकी application को निष्क्रिय होने से बचाया जा सके।
Application व्यवहार की समीक्षा करें

अकुशल API उपयोग patterns की पहचान के लिए अपने code का ऑडिट करें।
अनजाने loops या अनावश्यक API calls जांचें।
बड़े bursts भेजने के बजाय अनुरोधों को समय के साथ अधिक समान रूप से वितरित करें।

Caching implement करें

बार-बार access किए गए डेटा को cache करें जो शायद ही बदलता है।
OAuth2 access token का उपयोग उसके पूर्ण 1-घंटे TTL के लिए करें — प्रति अनुरोध `POST /oauth2/token` call न करें।
उचित cache invalidation strategies implement करें।

Polling के बजाय webhooks का उपयोग करें
`GET /client/v1/process/\{id\}` poll करने के बजाय `PROCESS_STATE_FINISHED` के लिए [Webhooks and Events](/hi/developers/webhooks-and-events) subscribe करें। एक polling loop भारी traffic पर GET-process budget को आसानी से समाप्त कर सकता है।
### Limit से टकराने पर क्या होता है​

प्लेटफ़ॉर्म लौटाता है:
```
HTTP/1.1 429 Too Many RequestsRetry-After: 12
```

Headerअर्थ`Retry-After`पुनः प्रयास करने से पहले प्रतीक्षा करने के सेकंड। इसका सम्मान करें।
यदि `Retry-After` अनुपस्थित है, तो exponential backoff (1s, 2s, 4s, 8s, …) 60s पर capped पर वापस जाएं।
### Concurrency considerations​

Rate limits प्रति मिनट अनुरोधों को cap करती हैं, लेकिन प्लेटफ़ॉर्म पर infrastructure स्तर पर **concurrency caps** भी हैं। भले ही आपके पास 100 requests/minute का budget हो, सभी 100 को एक ही सेकंड में fire करना उन्हें मिनट भर फैलाने से ज़्यादा reject होने की संभावना है।
High-throughput integrations के लिए, bursts के बजाय steady RPS target करें।
### Magic Link webhook delivery​

Trully के Webhook V2 के लिए अपने स्वयं के delivery quotas हैं। Webhook server से **1 मिनट** के भीतर प्रतिक्रिया की अपेक्षा है; धीमी प्रतिक्रियाएँ drop की जाती हैं (उपयोगकर्ता की process प्रभावित नहीं होती)। Consistent processing के लिए, webhook को तेज़ी से स्वीकार करें और इसे asynchronously process करें।
### आगे क्या​

[Authentication](/hi/dual-api/developers/api-reference/authentication) — token caching strategy।
[Webhooks and Events](/hi/developers/webhooks-and-events) — polling को push से बदलना।
[Error codes > Retry policy](/hi/dual-api/developers/api-reference/error-codes#retry-policy) — कब (और कब नहीं) retry करें।
अंतिम अपडेट 8 अक्टू॰ 2026** को