Skip to main content
لخّص عدد الطلبات والمقدار الفعلي المخصوم للحساب الحالي حسب التاريخ وAPI، وهو مناسب لإنشاء التقارير الشهرية ومخططات الاتجاهات وتحليل التكاليف. عند الحاجة إلى استكشاف الأخطاء لكل سجل على حدة، استخدم قائمة سجلات الاستدعاء، وعند الحاجة إلى تفاصيل كاملة دون اتصال، استخدم تصدير حجم الاستدعاءات.

الأعمال التحضيرية

  1. سجّل الدخول إلى منصة AceDataCloud.
  2. أنشئ رمز حساب في وحدة تحكم Account Token، واحفظه فورًا.
  3. إذا كنت بحاجة إلى تضييق النطاق، احصل على المعرف المناسب من قائمة طلبات الخدمة، أو قائمة بيانات اعتماد API، أو قائمة API.
للاطلاع على شرح كامل للرمز، راجع إدارة رموز الحساب. تستخدم هذه الواجهة Account Token، ولا تستخدم Credential الخاص بالأعمال.

نظرة عامة على الواجهة

معاملات الاستعلام

يمكن الاستمرار في استخدام start_time / end_time كأسماء مستعارة متوافقة مع العملاء القدامى، وتستخدم عمليات التكامل الجديدة بشكل موحّد created_at_from / created_at_to. تتضمن صيغة التاريخ لـ created_at_to ذلك اليوم التقويمي، أي يتم استخدام منتصف ليل اليوم التالي كحد فاصل.

أمثلة على الطلبات

استعلم عن الملخص اليومي/API للشهر الحالي بتوقيت بكين، مع تضمين بُعد النموذج:
استعلم عن استخدام أسبوع لـ Application محدد:
مثال Python:

مثال على الاستجابة

حقول الاستجابة

تعتمد وحدة الرصيد على service.unit الخاص بـ Application ذي الصلة. إذا تضمّن الاستعلام خدمات بوحدات مختلفة، فيرجى إجراء الإحصاءات بشكل منفصل حسب service_id أو application_id أولًا، لتجنب المقارنة المباشرة أو الجمع. عندما لا يكون وقت النهاية أكبر من وقت البداية، تُرجع الواجهة بنية فارغة كاملة: items=[]، وtotal=0، وapis={}، وrequests=0، وmodels=[].

اقتراحات الأخطاء والأداء

  • لا تفعّل include_models افتراضيًا؛ فعّله فقط عندما يحتاج التقرير فعلًا إلى تقسيم حسب النموذج.
  • بالنسبة إلى الاستعلامات واسعة النطاق، أعطِ الأولوية للفصل حسب service_id أو application_id، لتجنب خلط الوحدات وتقليل تكلفة الاستعلام أيضًا.
  • لا تُملأ التواريخ التي لا تحتوي على استدعاءات تلقائيًا بصفر؛ ينبغي للعميل إكمال محور التواريخ قبل الرسم.

الخطوة التالية