مطابقة استخدام CAPTCHA مع رصيد مساحة عملك

تُصادَق طلبات API باستخدام مفتاح API لمساحة عمل. تحقّق من مساحة العمل تلك عند مطابقة الاستخدام؛ فاشتراك الطلبات في اسم مضيف مستهدف لا يعني أنها تنتمي إلى مساحة العمل نفسها.

يحمل عرض الاستخدام في /usage تسمية آخر 28 يومًا. ويعرض Request volume وSuccessful وFailed (not billed) وAverage latency، وإما Period spend أو Unlimited coverage. لا تستنتج وجود فاتورة مطابقة أو قيمة الرصيد الحالي من تلك النافذة الزمنية وحدها.

استخدم By site profile لتحديد مصدر الارتفاع المفاجئ. قارن Site وShare وRequests لمعرفة موضع زيادة الحجم، ثم افحص Success وBilling. هذه أحداث استخدام للخدمة، وليست دليلًا على أن الموقع المستهدف قد قبل الطلبات الناتجة.

تُحتسب تكلفة المهمة ذات الحالة ready. وتُرد تكلفة عملية الحل الفاشلة. إنشاء مهمة أو تلقي استجابة HTTP ناجحة لا يعادل تلقي حل قابل للاستخدام؛ وحدها الحالة ready تتضمن حلًا.

إذا أعادت خدمة الحل حلًا جاهزًا لكن الموقع رفض الطلب اللاحق، فلا يُعد ذلك فشلًا لمهمة خدمة الحل. لا تحتسبه ضمن Failed (not billed) ولا تفترض رد تكلفته تلقائيًا. المهمة البديلة التي تصل إلى ready هي عملية حل أخرى تُحتسب تكلفتها.

الحد الأدنى لإيداع الرصيد هو $10؛ ورصيد الترحيب هو $5. يضيف الإيداع رصيدًا إلى مساحة العمل، ولا يعبّر عن المبلغ الذي أُنفق خلال فترة الاستخدام. افصل بين الرصيد المشترى ورصيد الترحيب عند مقارنة مدفوعاتك بالرصيد.

استخدم المهام الجاهزة المفوترة، وليس إجمالي عدد الطلبات، لتقدير تكلفة الدفع حسب الاستخدام. إذا عرضت لوحة التحكم Unlimited coverage، فتحقق من الخطة الشهرية المنطبقة الخاصة بالمنتج بدلًا من تسعير جميع الطلبات وفق الدفع حسب الاستخدام. وقد يغيّر رصيد الحساب أو أي رصيد إضافي منطبق مقدار الرصيد الإضافي الذي تحتاج إليه.

1. 1.

   طابق الموقع المتأثر والفترة الزمنية

   استخدم تفصيل الاستخدام حسب ملفات تعريف المواقع لتضييق نطاق البحث، ثم قارِن سجلات تطبيقك خلال الفترة نفسها. سجّل الطلب المنطقي وrequestId الخاص به ومعرّف المهمة المُعاد وحالتها النهائية.

2. 2.

   ابحث عن مهام متعددة تخدم طلبًا واحدًا

   قد تفسّر معرّفات مهام متعددة ومختلفة لعملية حل واحدة مقصودة الرسوم الإضافية إذا وصلت تلك المهام إلى حالة الجاهزية. ميّز بين عمليات الحل البديلة المتعمدة وإعادات المحاولة الناتجة عن فقدان استجابة.

3. 3.

   استرجع المهام لطلبات الإنشاء التي انتهت مهلتها

   انتهاء مهلة الاتصال لا يثبت فشل إنشاء المهمة. إذا كان لديك معرّف المهمة، فاسترجعها. وإلا، فأعِد إرسال طلب المهمة نفسه باستخدام requestId الأصلي لاسترجاع المهمة الموجودة بدلًا من إنشاء مهمة منطقية جديدة.

4. 4.

   عيّن requestId قبل المحاولة الأولى

   استخدم requestId واحدًا لكل عملية حل مقصودة واحتفظ به عند إعادة المحاولة. يقبل من 1–64 حرفًا من أحرف ASCII أو أرقامًا أو شرطات سفلية أو شرطات. يؤدي استخدام المعرّف نفسه مع طلب المهمة نفسه إلى إرجاع المهمة الموجودة؛ أما استخدامه مع مدخلات مختلفة فيؤدي إلى تعارض.

عند التحقيق في تكرار إنشاء المهام، احسب المهام المتميزة، لا محاولات HTTP فقط. فإعادات المحاولة المتعددة التي تُرجع معرّف المهمة نفسه لا تعني إنشاء مهام متعددة.