> ## Documentation Index
> Fetch the complete documentation index at: https://www.ayrshare.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# GraphQL सीमाएँ और Billing

> Ayrshare आपके API कोटा के विरुद्ध GraphQL requests की गिनती कैसे करता है, साथ ही query depth, फ़ील्ड, alias, directive, और request आकार की सीमाएँ।

<h2 id="how-requests-are-counted">
  Requests की गिनती कैसे होती है
</h2>

**प्रत्येक निष्पादित root operation फ़ील्ड एक API call है।** चार root फ़ील्ड्स माँगने वाली GraphQL request का शुल्क चार API calls के रूप में लिया जाता है, ठीक वैसे ही जैसे आपने चार REST requests की हों। Root पर aliases अलग-अलग गिने जाते हैं क्योंकि प्रत्येक एक ऑपरेशन dispatch करता है। किसी typed response से चुने गए nested फ़ील्ड्स API calls नहीं बढ़ाते।

```graphql theme={"system"}
{
  history: postHistory(lastDays: 7)
  accounts: user
  comments: comments(id: "abc123")
  analytics: socialAnalytics(platforms: [INSTAGRAM])
}
```

एक HTTP request, आपके plan के कोटा और rate limit के विरुद्ध **चार API calls**।

यह जानबूझकर है और यही ईमानदार मॉडल है: प्रत्येक root फ़ील्ड हमारी ओर उतना ही काम करता है जितना समकक्ष REST call, इसलिए इसकी लागत भी उतनी ही है। GraphQL आपके round trips बचाता है और आपको एक ही जगह पर ठीक वही प्राप्त करने देता है जो आपको चाहिए; यह आपके plan में शामिल API calls से अधिक calls पाने का तरीका नहीं है।

व्यावहारिक परिणाम:

<ul class="custom-bullets">
  <li>आपकी मौजूदा plan सीमाएँ बिना बदलाव के लागू होती हैं। अपने plan की सीमा के लिए <a href="/docs/apis/overview">API सीमाएँ</a> देखें।</li>
  <li>ऐसा root operation माँगना जिसकी आपको आवश्यकता नहीं है, उतना ही खर्च करता है जितना उसे REST पर कॉल करना। अपनी ज़रूरत के nested response फ़ील्ड्स चुनने से calls नहीं बढ़तीं।</li>
  <li>कोई request <em>बीच में ही</em> rate limit हो सकती है। जो root फ़ील्ड्स पूरे हो चुके हैं उनका डेटा बना रहता है, और केवल throttled root फ़ील्ड्स errors लौटाते हैं — <a href="/docs/apis/graphql/errors#partial-success">आंशिक सफलता</a> देखें।</li>
</ul>

<h2 id="query-limits">
  Query सीमाएँ
</h2>

Endpoint किसी query के आकार और साइज़ पर कुछ सीमाएँ लागू करता है। ये इसलिए हैं ताकि एक अकेली request हमारी क्षमता का अनुचित हिस्सा न ले सके, और इन्हें सामान्य उपयोग की आवश्यकता से काफ़ी ऊपर रखा गया है — यदि आप किसी सीमा तक पहुँच रहे हैं, तो यह आमतौर पर वास्तविक आवश्यकता के बजाय गलती से generate हुई query का संकेत होता है।

| सीमा | मान | आपको कैसे पता चलता है |
| - | - | - |
| प्रति request API calls | 5 | प्रत्येक अतिरिक्त root फ़ील्ड पर `extensions.status` 429 |
| Query nesting depth | 15 | Query चलने से पहले अस्वीकार |
| प्रति request फ़ील्ड्स | 300 | Query चलने से पहले अस्वीकार |
| प्रति request aliases | 25 | Query चलने से पहले अस्वीकार |
| प्रति request directives | 50 | Query चलने से पहले अस्वीकार |
| Request body का आकार | 64 KB | HTTP 413 |

अस्वीकृत query HTTP 400 लौटाती है यदि आप `Accept: application/graphql-response+json` भेजते हैं, और अन्यथा HTTP 200, दोनों स्थितियों में `errors` array के साथ और बिना `data` के। [त्रुटियाँ](/docs/apis/graphql/errors) देखें।

<h3 id="api-calls-per-request">
  प्रति request API calls
</h3>

यह महत्वपूर्ण है। एक अकेली request अधिकतम **5** API calls ट्रिगर कर सकती है, इसलिए ऊपर का चार-root-फ़ील्ड वाला उदाहरण ठीक है लेकिन बीस-root-फ़ील्ड वाला नहीं। पाँच dispatches शुरू हो जाने के बाद, अतिरिक्त root फ़ील्ड्स सीमा को समझाते हुए 429 लौटाते हैं; पहले से dispatch हो चुके फ़ील्ड्स फिर भी अपना डेटा लौटा सकते हैं।

यदि आपको अधिक की आवश्यकता है, तो query को कई requests में बाँट दें। यदि आप किसी वैध workload के लिए नियमित रूप से ऐसा कर रहे हैं, तो [हमसे संपर्क करें](/docs/help-center/overview) — launch के लिए यह सीमा जानबूझकर सावधानीपूर्वक रखी गई है और इसे बढ़ाना आसान है, जबकि बाद में इसे घटाने से integrations टूट जाएँगे, इसलिए यह छोटी शुरू होती है।

<h3 id="depth-fields-and-aliases">
  Depth, फ़ील्ड्स, aliases और directives
</h3>

इन्हें कुछ भी चलने से पहले जाँचा जाता है, इसलिए किसी एक को पार करने पर आपकी कोई API call खर्च नहीं होती।

ये पूरी introspection query से भी आराम से ऊपर हैं, जो लगभग 180 फ़ील्ड्स और 12 स्तर गहरी होती है और जिसमें कोई aliases या directives नहीं होते, इसलिए startup पर पूरा schema fetch करने वाला client सामान्य रूप से काम करता है।

<h3 id="request-body-size">
  Request body का आकार
</h3>

64 KB, जो किसी query के लिए पर्याप्त है और किसी फ़ाइल के लिए बहुत छोटा। यही कारण है कि मीडिया को GraphQL के माध्यम से अपलोड नहीं किया जा सकता — समर्थित तरीके के लिए [मीडिया अपलोड करना](/docs/apis/graphql/using-the-api#uploading-media) देखें।

<h2 id="timeouts">
  Timeouts
</h2>

एक request को कुल मिलाकर अधिकतम 120 सेकंड दिए जाते हैं। किसी **query के root फ़ील्ड्स समवर्ती रूप से चल सकते हैं**, इसलिए इसकी अवधि आमतौर पर इसकी सबसे धीमी dependency से निर्धारित होती है। किसी **mutation के root फ़ील्ड्स क्रमिक रूप से चलते हैं**, इसलिए कई धीमे mutations मिलकर timeout तक पहुँच सकते हैं। दोनों ही रूप backend पर अधिकतम पाँच समवर्ती या क्रमिक dispatches जितना लोड डाल सकते हैं; उचित होने पर ज्ञात-धीमे काम को बाँट दें।

<h2 id="what-is-not-limited">
  किन चीज़ों पर सीमा नहीं है
</h2>

<ul class="custom-bullets">
  <li><strong>Schema पढ़ना।</strong> Introspection बिना authentication के और बिना मीटरिंग के है। क्या-क्या मौजूद है, यह ब्राउज़ करना मुफ़्त है; कोई ऑपरेशन चलाना नहीं।</li>
  <li><strong>Malformed queries।</strong> GraphQL द्वारा अस्वीकृत query — अज्ञात फ़ील्ड, गलत type, अमान्य enum value — कभी हमारे API तक नहीं पहुँचती और उसका कभी शुल्क नहीं लिया जाता।</li>
</ul>

इन सीमाओं की समीक्षा वास्तविक उपयोग के आधार पर की जाती है। यदि इनमें से कोई किसी वैध integration के लिए अनुपयुक्त है, तो हमें बताएँ — वह feedback किसी workaround से अधिक उपयोगी है।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.