रेफ़रेंस
रेट लिमिट
सीमाएँ API को अचानक आई बाढ़ से बचाती हैं, सामान्य रीसेलर से नहीं। हर खाते की प्रति मिनट एक सीमा होती है जो उसके खर्च के साथ बढ़ती है, और भारी कार्रवाइयों के लिए कुछ सीमित सीमाएँ हैं। एक ऑर्डर से जुड़े नियम, जैसे रिफिल की प्रतीक्षा, 429 की जगह अपना एरर कोड लौटाते हैं।
Rate-limit layers
प्रति-IP
20,000 requests / मिनट / IP address
की वैलिडेशन से पहले लागू किया जाता है ताकि ब्रूट-फ़ोर्स की enumeration सीमित रहे। एक ही IP के पीछे की सभी की में शेयर किया जाता है। डिफ़ॉल्ट ग्लोबली सेट होता है और यूज़र-कॉन्फ़िगरेबल नहीं है।
Shared account window
Rolling 60 seconds में 120–2,400 requests
एक account की सभी active API कुंजियाँ एक ही counter इस्तेमाल करती हैं। Direct RPM override न होने पर lifetime successful-spend ladder limit देता है।
Action-specific
Action पर निर्भर
Services, catalog, cancel, refill और webhook कार्रवाइयों की अपनी सीमित सीमाएँ हैं, जो नीचे दिखाई गई हैं। ये खाते की सीमा में जुड़ती हैं; उसकी जगह नहीं लेतीं।
प्रति-कार्रवाई सीमाएँ
ये सीमाएँ प्रति खाता प्रति मिनट गिनी जाती हैं। इनमें से किसी से आया 429 X-RateLimit-DeniedBy में action बताता है। Cancel और refill अनुरोध नहीं, ऑर्डर आईडी गिनते हैं, इसलिए 10 ऑर्डर के लिए एक कॉल आपके प्रति मिनट के आईडी में से 10 खर्च करती है। इससे ज़्यादा आईडी, 100 तक, वाला cancel या refill तब स्वीकार होता है जब वह मिनट की आपकी पहली कॉल हो, और वह पूरा मिनट खर्च कर देता है।
| कार्रवाई | प्रति मिनट | क्या गिना जाता है |
|---|---|---|
| services | 10 | अनुरोध |
| catalog | 30 | अनुरोध |
| cancel | 30 | ऑर्डर आईडी |
| refill | 30 | ऑर्डर आईडी |
| webhook.* | 10 | अनुरोध |
Lifetime successful-spend ladder
आपके खाते की सीमा आपके जीवनकाल के सफल खर्च के अनुसार चलती है; ऊँचा स्तर तुरंत ऊँची सीमा खोल देता है। कुंजी जाँचे जाने से पहले प्रति मिनट 20,000 अनुरोधों की IP सीमा लागू होती है। एडमिन किसी खाते के लिए सीधी सीमा तय कर सकता है, अधिकतम 10,000 तक। आपके खाते का स्तर X-RateLimit-Tier हेडर में और आपके API पेज पर है।
| Tier | Minimum lifetime spend | Requests / मिनट |
|---|---|---|
| 0 | $0 | 120 |
| 1 | $10 | 300 |
| 2 | $50 | 600 |
| 3 | $100 | 900 |
| 4 | $500 | 1,200 |
| 5 | $1,000 | 1,800 |
| 6 | $2,500 | 2,400 |
रिस्पॉन्स हेडर
रिस्पॉन्स हेडर
X-RateLimit-Limit- सामान्य response में account का effective shared requests-per-minute limit। 429 पर rejecting layer द्वारा बताया गया limit।
X-RateLimit-Remaining- सामान्य response में shared account window की बची requests। 429 पर rejecting layer द्वारा बताई गई remaining value।
X-RateLimit-Reset- बताई window reset होने तक relative seconds; यह Unix timestamp नहीं है।
X-RateLimit-Tier- Lifetime successful spend से मिला tier (0–6)। Custom RPM override इस value को नहीं बदलता।
X-RateLimit-DeniedBy- जब कोई named limiter call रोकता है, 429 response में भेजा जाता है: "ip", "api_requests_per_minute" या "action"।
Retry-After- Retryable 429 या 503 में Retry-After के बताए seconds से कम नहीं प्रतीक्षा करें। action=add के लिए प्रतीक्षा के बाद वही idempotency key फिर इस्तेमाल करें।
429 रिस्पॉन्स संभालना
जब Retry-After मौजूद हो तो उसका इंतज़ार करें।
अन्यथा X-RateLimit-Reset के सेकंड तक प्रतीक्षा करें। दोनों मान सापेक्ष देरी हैं, घड़ी का समय नहीं; दोबारा कोशिश से पहले रैंडम जिटर जोड़ें।X-RateLimit-DeniedBy पढ़ें।
यह उस सीमा का नाम बताता है जिसने कॉल अस्वीकार की। कुंजी बदलने से मदद नहीं मिलती, क्योंकि खाते, IP और कार्रवाई की सीमाएँ साझा हैं।पोलिंग के बजाय webhooks इस्तेमाल करें।
Webhooks कम से कम एक बार पहुँचते हैं, इसलिए अपने हैंडलर को idempotent रखें और कुछ भी महत्वपूर्ण जाँचने के लिएaction=statusइस्तेमाल करें।जहाँ हो सके बैच करें।
Status, cancel और refill एक अनुरोध में अधिकतम 100 आईडी लेते हैं; ऑर्डर आईडी की गिनती cancel और refill पर फिर भी लागू होती है।