أخطاء

تستخدم أخطاء فتح API أجسام استجابة JSON عندما يصل الطلب إلى طبقة API. قد لا يكون لحالات فشل الشبكة وفشل CDN وانقطاعات الاستجابة الثنائية هذا الشكل الدقيق، لذلك يجب على العميل الخاص بك التعامل مع كل من أخطاء API المنظمة وأخطاء النقل.

تستخدم كل نقطة نهاية نفس سياق مصادقة الحامل:

Authorization: Bearer KITTA_API_KEY

{
  "code": "invalid_request",
  "message": "The request payload is invalid.",
  "requestId": "req_xxx"
}

رموز الحالة

تسجيل الطلب

قم بتسجيل نقطة النهاية وطريقة HTTP والحالة وcode وrequestId ومعرف الوظيفة الداخلي الخاص بك. لا تقم بتسجيل مفاتيح API الحاملة أو نص المستخدم الكامل أو عناوين URL للوسائط الخاصة ما لم تسمح سياسة الخصوصية وسير عمل الدعم بذلك بشكل صريح.

بالنسبة لنقاط النهاية غير المتزامنة، قم بتضمين معرف المهمة API ومعرف قاعدة البيانات الداخلية في السجلات. وهذا يجعل من الممكن التوفيق بين عمليات إعادة المحاولة دون إنشاء عمل مكرر.

الفواتير والائتمانات

ليس كل خطأ له نفس معنى الفواتير. عادةً ما تحدث حالات فشل التحقق من الصحة قبل بدء العمل الإعلامي. قد تحدث حالات فشل في المعالجة بعد قبول المهمة. بالنسبة لأسئلة الفوترة التي يواجهها المستخدم، قارن حالة المهمة بقراءة ملف تعريف جديدة بدلاً من استنتاج التكلفة من حالة HTTP وحدها.

سياسة إعادة المحاولة

أعد محاولة 429 وبعض استجابات 500 مع التراجع. لا تقم بإعادة محاولة 400 أو 401 أو 402 بشكل أعمى؛ تلك تتطلب تغييرات في الطلب أو بيانات الاعتماد أو الفواتير. لإنشاء نقاط النهاية، استمر في المعرف الذي تم إرجاعه قبل إعادة محاولة أي عملية متابعة.