Skip to main content
لكل مفتاح نافذته الخاصة: 120 طلبًا كل 60 ثانية افتراضيًا. هذا سقف تشغيلي ضد إساءة الاستخدام، لا حصة خطة. الاستخدام نفسه يُقاس برصيد المالك لا بهذا العدّاد، ومفاتيح المالك نفسه لا تتشارك النافذة. تعمل المصادقة قبل المحدّد، لذلك الطلب غير المصادق لا ينفق أبدًا من ميزانية المفتاح.

الترويسات

ردود JSON الناجحة (200) والرد 429 تحمل حالة النافذة: رد text/event-stream الخاص بنقطة نهاية الرد المتدفق وأغلفة الأخطاء الأخرى (401، 403، 404، 409، 422، 503، 500) لا تحمل هذه الترويسات؛ الترويسة X-Request-ID وحدها موجودة في كل رد. إذا كنت تضبط وتيرة عميلك على X-RateLimit-Remaining، فعامل الترويسة المفقودة على أنها «غير معروفة» لا صفرًا. عندما تُستنفد النافذة تجيب API بـ 429 rate_limit_exceeded وتضيف Retry-After (الثواني حتى إعادة النافذة).

عندما يتوقف المحدّد نفسه

المحدّد يفشل بالإغلاق. إذا كان مخزنه غير متاح، تجيب API بـ 503 api_rate_limit_unavailable مع Retry-After: 5 بدلًا من تمرير الطلبات بلا قياس، وبدلًا من 429 مضلل. عامله كأي خطأ عابر آخر: انتظر ثم أعد المحاولة بنفس Idempotency-Key.
لا توزّع الحركة على عدة مفاتيح للوكيل نفسه لرفع السقف. لكل مفتاح محادثاته الخاصة، فينتهي المستخدم النهائي نفسه بسجل مجزأ. إذا احتجت إلى حد أعلى، تواصل معنا.

ضبط الوتيرة من جهة العميل