Logs panel
كل طلب API عمله حسابك: الطريقة، والمسار، والحالة، والترويسات، والمحتوى، والرد. صفِّ حسب الخطأ، أو المورد، أو المصدر.
تاب Logs هو عرض كل اللي ضرب على حسابك على مستوى الطلب: كل استدعاء API، وكل تعديل من لوحة التحكم، مع الطريقة، والمسار، والحالة، ومحتوى الطلب، ومحتوى الرد، والترويسات، وتفاصيل الخطأ لو الطلب فشل. ده التاب اللي بتلجأ ليه لما استدعاء في الدمج يرجّع 400 وعايز تشوف بالظبط XPay استلم إيه ورد بإيه.
لميكانيكية الدرج (الفتح، السحب، الشاشة الكاملة)، شوف مقدمة الـ Workbench.
افتح التاب
اضغط أيقونة السهمين (لأعلى ولأسفل) اللي في القائمة أسفل يمين لوحة التحكم. الـ Workbench بيفتح على تاب Logs مفلتر مسبقًا على آخر 24 ساعة.
تقدر كمان تفتح الـ Workbench بأي طريقة تانية وتبدّل لـ Logs في شريط التابات.
فلتر القائمة
تلات فلاتر ظاهرة فوق القائمة، زائد نافذة More filters لكل حاجة تانية.
| الفلتر | بيعمل إيه |
|---|---|
| Resource ID | بحث نصّي حر. لاقي كل طلب مسّ pi_* أو cs_* أو cus_* معيّن، وهكذا. |
| Date | آخر N ساعة / يوم، في يوم معيّن، أو بين تاريخين. افتراضيًا آخر 24 ساعة لما تفتح التاب من أيقونة القائمة. |
| Status | Succeeded (2xx) أو Failed (4xx و5xx). اختار واحد علشان تضيّق القائمة. |
| More filters (نافذة) | طريقة HTTP، ومسار نقطة نهاية الـ API، وعنوان الـ IP، والمصدر (Dashboard / API)، وكود الخطأ، ونوع الخطأ، وبارامتر الخطأ. |
زرار Clear filters بيظهر بمجرد ما تظبط أي فلتر. العدد الكلي على اليمين (مثلًا 42 logs) بيعكس المجموعة المفلترة.
زرار "More filters" بيعرض شارة عدد (+3، +5) لما يكون فيه فلاتر إضافية مفعّلة علشان ما تفقدش اللي بيضيّق العرض.
قراءة القائمة
السجلات متعروضة من الأحدث للأقدم، مجمّعة تحت عناوين التواريخ (Today، Yesterday، وبعدها تاريخ). كل صف بيحمل:
- شارة حالة:
200 OK(أخضر) أو4xx ERR/5xx ERR(أحمر) مع الكود الفعلي. - طريقة HTTP (بلون مميّز لكل طريقة).
- المسار (مقصوص علشان يلائم المساحة).
- الوقت.
اضغط على صف علشان تدخل بالتفصيل على الطلب. استخدم Load more في الأسفل علشان تتصفّح التاريخ.
قراءة طلب
لوحة التفاصيل بتعرض الطلب والرد بالكامل. شريط الهيدر بيحمل الطريقة، والمسار، وشارة الحالة. تحت كده:
| الحقل | يعني إيه |
|---|---|
| Request ID | الـ req_* بتاع الطلب. ثابت عبر إعادات المحاولة. اذكره لما تتواصل مع الدعم. |
| Time | تاريخ ووقت الطلب، بدقة الثانية. |
| Duration | زمن الرد من ناحية السيرفر بالميلي ثانية. |
| IP Address | الـ IP بتاع العميل. مفيد في تتبّع الاستدعاءات المؤتمتة. |
| Origin | قيمة ترويسة Origin، لما تكون موجودة. |
| Idempotency Key | قيمة ترويسة Idempotency-Key من الطلب، لو بعتّ واحدة. |
| API Key | أول كام حرف من المفتاح السرّي المستخدَم، محجوبة. بتخلّيك تعرف أنهي مفتاح عمل الاستدعاء من غير ما تكشفه أبدًا. |
| Source | "Dashboard" (واسم عضو الفريق) للتعديلات اللي جت من لوحة التحكم، وغير كده استدعاء API. |
| User Agent | ترويسة User-Agent بتاعة العميل. |
لو الطلب رجّع خطأ، قسم Error Insight بيجي بعد البيانات الوصفية: رسالة الخطأ المقروءة للبني آدم، زائد الـ errorType وerrorCode وerrorParam المنظّمين (كل واحد قابل للضغط كفلتر سريع).
تحت كده، أربع أقسام للحمولات بتظهر لما تكون موجودة:
- Response Body: الـ JSON اللي XPay رجّعه. لطلبات
GETالناجحة، اللوحة بتعرض ملاحظة حرفية: "XPay doesn't store the response body from successful GET requests." ردود POST / PATCH / DELETE الناجحة بتتخزّن. - Request Body (العنوان بيبقى
Request POST Body/Request PATCH Body/Request DELETE Bodyعلى حسب الطلب): الـ JSON اللي بعتّه. - Query Parameters: سلسلة الاستعلام المفكّكة، مفتاح بمفتاح.
- Request Headers: كل ترويسة XPay استلمها، شاملة ترويسة المصادقة (محجوبة بالفعل).
كل قسم بيستخدم نفس عارض الـ JSON الموجود في باقي الـ Workbench: المفاتيح قابلة للضغط، والمعرّفات مرتبطة بروابط، والكائنات الكبيرة بتتطوي افتراضيًا.
الاحتفاظ بالبيانات
سجلات طلبات الـ API بتتحفظ لمدة 30 يوم. بعد 30 يوم الصف بيتشال فعليًا وبيختفي من التاب. تاب Events وتسليمات الـ webhook ليهم فترات احتفاظ منفصلة؛ شوف Events panel.
لو محتاج تاريخ الطلبات لأبعد من 30 يوم، اشحن سجلاتك من السيرفر بتاعك. الـ Workbench أداة debug في الوقت الحقيقي، مش أرشيف طويل المدى.
استخدام نموذجي
تلات دورات تاب Logs بيستاهل عشانهم:
- استدعاء API حقيقي رجّع 400 وعايز تعرف ليه. افتح أيقونة القائمة، التاب بيستقر مفلتر مسبقًا على آخر 24 ساعة. صفِّ حسب
Status: Failed. اضغط على الصف. قسم Error Insight بيسمّي الحقل اللي فشل في التحقق؛ ومحتوى الطلب بيعرض اللي بعتّه. - منطق إعادة المحاولة عندك كرّر حاجة. فلتر حسب
Idempotency Key(أو حسبResource IDبتاع المورد اللي اتأثّر). قارن الصفين جنب بعض. لوحة التفاصيل بتوضّح لو الاتنين نجحوا ولا واحد كان بلا أثر (no-op). - مستخدم في لوحة التحكم غيّر حاجة ما كنتش متوقّعها. فلتر
Source = Dashboard. حقل Source في كل صف بيقولك أنهي عضو فريق عمل التغيير.
سياق الـ Inspector
لما تاب Logs بيتعرض جوّه تاب Inspector كتاب فرعي (بدل ما يكون تاب Logs الرئيسي)، بيتحصر تلقائيًا على المورد اللي بتفحصه. فلتر الـ Resource ID بيتخفي، و"Include related" بيبقى ضمنيًا فبتشوف كمان السجلات اللي مسّت الموارد اللي حواليه (مثلًا لـ Payment Intent، السجلات اللي مسّت الـ Charges والـ Refunds بتاعته). نفس الفلاتر فيما عدا كده. شوف Inspector.
رايح فين بعد كده
مقدمة الـ Workbench
ميكانيكية الدرج، والتابات الأربعة بنظرة سريعة، وإزاي تفتح الـ Workbench.
Inspector
ادخل بالتفصيل على مورد معيّن وشوف سجلاته، وأحداثه، والرسم اللي حواليه.
Events panel
أحداث webhook، والتسليمات، والمحاولات. النص التاني من قصة الـ debugging.
Health panel
مجموعات الأخطاء المجمّعة عبر الطلبات الأخيرة.
الأخطاء
مغلّف الخطأ، والقائمة الكاملة لقيم errorCode وerrorType، وإزاي تتعامل معاهم.
نموذج الكائنات
فلتر Resource ID بيقبل إيه وإزاي الموارد بتتركّب مع بعض.