Skip to main content
تفرض واجهة /v1 البرمجية حدَّين مستقلين للطلبات. يُرفض الطلب إذا استُنفد أي من الحدَّين. يتبع الحد المخصص لكل مفتاح المفتاحَ أينما استُخدم. أما الحد المخصص لكل عنوان IP فهو الحد الوحيد لحركة البيانات غير الموثَّقة، وسقف ثانٍ لحركة البيانات الموثَّقة.
تُطبَّق الحدود قبل المصادقة، لذا فإن الطلبات ذات بيانات الاعتماد غير الصالحة أو المفقودة تُحتسب أيضًا ضمن حد المصدر. الحدود الرقمية الدقيقة يحددها المشغّل وقد تتغير، ويمثّل عقد الاستجابة الوارد أدناه الواجهة الثابتة التي ينبغي البناء عليها.
قم بالمصادقة باستخدام أي من صيغتي بيانات اعتماد Basic — راجع البدء السريع (apikey:secret أو secret:). عيّن BASE إلى المضيف الإقليمي للمؤسسة — راجع المناطق.

الاستجابة 429

عند استنفاد أحد الحدود، تُرجع الواجهة البرمجية 429 Too Many Requests مع ترويسة Retry-After (بالثواني) ومتن تفاصيل المشكلة القياسي:
429 Too Many Requests
لا توضح الاستجابة أي الحدَّين قد استُنفد. تعامل مع كل استجابة 429 بالطريقة نفسها: انتظر، ثم أعد المحاولة.

التعامل مع استجابات 429

1

الالتزام بـ Retry-After

انتظر مدة لا تقل عن عدد الثواني الوارد في ترويسة Retry-After قبل إعادة المحاولة. إن إعادة المحاولة قبل ذلك تستهلك الحد مجددًا في طلبات سيتم رفضها.
2

التراجع الأسي عند تكرار الرفض

إذا رُفضت إعادة المحاولة مرة أخرى، فزد مدة التراجع وأضف تباينًا عشوائيًا حتى لا تعيد المهام المتوازية المحاولة في الوقت نفسه. لا تقلّص قيمة Retry-After التي يحددها الخادم لتناسب حدًا محليًا. وإذا طلب منك الخادم الانتظار مدة أطول مما تسمح به ميزانية إعادة المحاولة لديك، فتوقف وجدوِل العمل لوقت لاحق.
3

تسوية معدل الطلبات

فضّل معدل طلبات ثابتًا على الدفعات المفاجئة. بالنسبة إلى عمليات القراءة المجمّعة، استخدم الحد الأقصى لحجم الصفحة (limit=500) لتغطية المجموعة بعدد أقل من الطلبات — راجع ترقيم الصفحات. وعند تشغيل عدة عمليات تصفح للقوائم بالتوازي (مثل جداول Power BI)، أبقِ التزامن معتدلًا والتزم بـ Retry-After حتى لا يتسبب رفض مؤقت بالاستجابة 429 في فشل عملية التحديث بالكامل.
يعيد هذا المثال المحاولة فقط عند استجابات 429 لطلب GET، بحد أقصى خمس محاولات وبحد أقصى 60 ثانية من الانتظار بين المحاولات. ويتوقف فورًا عند الأخطاء الأخرى. وتنتقل مهلات الشبكة إلى المستدعي. اضبط المهلات وميزانيات إعادة المحاولة بما يناسب حمل العمل لديك. يفسّر requests مهلة القراءة على أنها الحد الأقصى لمدة الخمول أثناء استلام البيانات، وليست مهلة إجمالية. حمّل LIVING_SECURITY_API_KEY من مدير الأسرار لديك. ثبّت requests قبل تشغيل هذا المثال. استدعِ get_with_retry("/organization") لاستخدامه.
Python
لا تنسخ هذه الحلقة حول عملية كتابة. فقد تعني مهلة تنتهي بعد عملية كتابة أن الخادم أتمّها قبل انقطاع الاتصال. لا تكرر عملية الكتابة إلا إذا كان مرجع تلك العملية يوثّق صراحةً إمكانية تكرارها بأمان (idempotency)، مع الإبقاء على المفتاح نفسه والحمولة نفسها. وفيما عدا ذلك، تحقق من حالة المورد قبل المحاولة مجددًا.

جدول التحديث الموصى به

حدِّد وتيرة التحديث بما يتناسب مع حد المفتاح لديك وحجم الصفحة. إن التحميل التاريخي الكامل لمجموعة كبيرة تكلفة تُدفع مرة واحدة؛ فضّل النوافذ التدريجية لعمليات التحديث في الحالة المستقرة بحيث تبقى كل عملية ضمن الحد بفارق مريح. اضبط دائمًا limit=500 صراحةً — فالقيمة الافتراضية 25 تضاعف عدد الطلبات.