Skip to main content

الغلاف

كل إخفاق، أيًا كانت الحالة، هو كائن JSON واحد:
  • code ثابت وقابل للقراءة آليًا. تفرّع عليه لا على message.
  • message شرح مقروء للبشر وقد يتغير.
  • request_id هو UUID الطلب. يُعاد أيضًا في الترويسة X-Request-ID في كل رد، نجاحًا كان أم فشلًا. اذكره عند الإبلاغ عن مشكلة.
في نقطة نهاية الرد المتدفق، الإخفاق الذي يحدث بعد بدء التدفق يصل كحدث error بنفس الحقول الثلاثة؛ راجع الرد المتدفق.

الرموز

يُفحص agent_not_found وagent_disabled فقط في POST …/chat وPOST …/chat/stream. نقطتا نهاية GET لا تنظران إلى حالة الوكيل: مفتاح وكيل معطّل ما زال يستطيع عرض محادثاته وقراءة رسائله.

ما الذي يُعاد محاولته

idempotency_in_progress، conversation_busy، rate_limit_exceeded، api_rate_limit_unavailable، service_unavailable. إعادة استخدام المفتاح تضمن ألا تدفع مرتين للرسالة نفسها.
validation_error (اقرأ message؛ فهي تسمّي الحقل المخالف)، idempotency_conflict (استخدم مفتاحًا جديدًا للجسم الجديد)، permission_denied (استخدم مفتاح fullagent_mismatch (استخدم الوكيل الذي ينتمي إليه المفتاح).
invalid_api_key (المفتاح حُذف أو السر خاطئ)، agent_disabled، agent_not_found، insufficient_balance (اشحن الرصيد أولًا). حلقة إعادة المحاولة على هذه الرموز لا تفعل سوى استنزاف حد المعدل.
internal_error. أعد المحاولة مرة واحدة بنفس Idempotency-Key: السجل الفاشل يُحرَّر، فتشغّل إعادة المحاولة الطلب من جديد بدلًا من إعادة نتيجة مخزّنة. هذا متوقع، لكنه ليس مضمونًا أن يكون مجانيًا. إذا حدث الإخفاق بعد أن أجاب النموذج بالفعل، تنتج إعادة المحاولة ردًا جديدًا وخصمًا جديدًا. إذا استمر الإخفاق، أرسل إلينا request_id.

ملاحظة حول 401

لا تفرّق API بين مفتاح محذوف ومفتاح لم يوجد قط: كلاهما invalid_api_key. إذا بدأ مفتاح كان يعمل بإرجاع 401، تحقق من بطاقة الوصول عبر API في التطبيق؛ فالأرجح أنه دُوِّر أو حُذف.