Skip to main content
يُخبر كائن webhook المنصة كيف تعالج طلبات HTTP الواردة من مزوّدك. هذا هو جوهر التكامل القائم على الأحداث. عنوان الويب هوك الخاص بك: https://{saas-api-url}/miniapps/{ns}/webhooks هذا العنوان يُولَّد تلقائياً ومتاح كـ {{webhookUrl}} في طلبات التسجيل.
ليست ويب هوك المستأجر — هذه ويب هوك مزوّد واردة (مثل Salla → كرزون). لأحداث مساحة العمل الصادرة إلى خادمك، راجع ويب هوك المستأجر.

استخراج الحدث

يخبر المنصة أين تجد اسم الحدث في طلب الويب هوك الوارد. استخراج بسيط (حقل واحد):
أمثلة:
  • ترسل Salla { "event": "order.created", "data": {...} }source: 'body', path: '$.event'
  • خدمة ترسل اسم الحدث في ترويسة ← source: 'header', path: 'X-Event-Type'
استخراج مركّب (متعدد الحقول): بعض المزوّدين يقسمون تعريف الحدث عبر حقول متعددة. استخدم compositeStrategy لدمجها:
مثال آخر — يستخدم Slack حقول الجسم:

إلغاء تكرار المعاملات

يمنع معالجة الويب هوك نفسه مرتين (مثلاً أثناء إعادة المحاولة).
تتحقق المنصة من Redis لمعرّف المعاملة. إذا عُولج مسبقاً، يُقرّ الويب هوك بصمت دون إعادة المعالجة. أنماط شائعة:
  • '$.data.id' — معرّف طلب/سلة Salla
  • '$.delivery' — ترويسة delivery في GitHub
  • '$.event_id' — حقل معرّف حدث عام

التحقق (توقيعات HMAC)

تحقق من أن الويب هوك الواردة تأتي فعلاً من مزوّدك باستخدام التحقق بتوقيع HMAC.
أنواع التحقق: encoding اختياري لأنواع HMAC: 'hex' (الافتراضي) أو 'base64' (WooCommerce X-WC-Webhook-Signature). كيف يُحلّ السر (secretKey): حقل secretKey هو اسم مفتاح، وليس قيمة السر نفسها. تحلّ المنصة السر الفعلي ببحث من مصدرين:
  1. بيانات اعتماد لكل مستأجر — تتحقق أولاً من installedMiniApps.credentials[secretKey]. استخدم هذا عندما يُصدر المزوّد سراً فريداً لكل متجر/مستأجر متصل (مثلاً تسجيل ويب هوك يعيد مفتاح توقيع لكل متجر).
  2. إعداد التطبيق العام — الرجوع إلى miniApp.auth.config[secretKey] إن لم يُوجد في بيانات اعتماد المستأجر. استخدم هذا عندما يستخدم المزوّد سراً عاماً واحداً مشتركاً بين جميع المستأجرين (مثل Salla، حيث يُضبط سر الويب هوك مرة واحدة في لوحة الشريك).
للأسرار العامة، اضبط القيمة في auth.config ضمن تعريف ميني أب الخاص بك. لأسرار لكل مستأجر، خزّنها في credentials أثناء طلبات التسجيل أو تدفق OAuth.
كيف يعمل تحقق HMAC:
  1. تقرأ المنصة التوقيع من headerName
  2. تزيل البادئة sha256= أو sha1= إن وُجدت
  3. تحلّ السر عبر بحث المصدرين الموضّح أعلاه
  4. تحسب HMAC لجسم الطلب الخام باستخدام السر المحلول
  5. تقارن بمقارنة آمنة زمنياً لمنع هجمات التوقيت
  6. ترفض بـ 401 إن لم يتطابقا

استجابة التحدي / المصافحة

بعض المزوّدين (مثل Slack) يتطلبون مصافحة تحدٍّ–استجابة عند تسجيل الويب هوك.
كيف تعمل:
  1. يرسل المزوّد POST مع { "type": "url_verification", "challenge": "abc123" }
  2. تتحقق المنصة: body.type === 'url_verification' ← نعم، هذا تحدٍّ
  3. تستخرج المنصة رمز التحدي من $.challenge"abc123"
  4. ترد المنصة بـ { "challenge": "abc123" }
  5. يعتبر المزوّد عنوان الويب هوك موثَّقاً
إذا حُذف responseField، يُرجع رمز التحدي كجسم استجابة خام.

استخراج العميل

لميني أب التي تستقبل بيانات عملاء في الويب هوك (منصات التجارة الإلكترونية، أنظمة CRM)، اضبط إنشاء/مطابقة العملاء تلقائياً.
حقول العميل المتاحة: كيف تعمل: عند وصول ويب هوك، تقوم المنصة بـ:
  1. استخراج بيانات العميل من basePath (أو مسار التجاوز للحدث المحدد)
  2. تعيين أسماء حقول المزوّد إلى أسماء الحقول الداخلية
  3. استدعاء getOrCreateCustomer() الذي يجد أو ينشئ سجل العميل
  4. ربط العميل بالحدث الوارد لسياق الأتمتة

إعداد الاستجابة

عرّف ما ترسله المنصة إلى مزوّدك بعد استلام الويب هوك.
ترسل المنصة الاستجابة فوراً عند استلام الويب هوك، قبل بدء المعالجة غير المتزامنة. هذا يمنع مهلات المزوّد. استخدم 202 إذا كان مزوّدك يتوقع استجابات بأسلوب الإقرار.
آخر تعديل في ٨ أغسطس ٢٠٢٦