Skip to main content
يقوم محرك webhook بدفع تحديثات calendar وsignal وsentiment مباشرةً إلى نقطة نهاية HTTP لديك مع محاولات إعادة تلقائية مضمّنة وخيارات للتصفية والتحويل. استخدم هذا الدليل لفهم آلية التسليم، وبنية الحمولة، وأفضل ممارسات التكامل.

نظرة عامة

تقوم خدمة Webhook لبيانات Benzinga بإرسال بيانات التقويم (calendar) والإشارات (signals) في الوقت الفعلي إلى نقاط الـ webhook التي قمتَ بتهيئتها. عند إنشاء أو تحديث أو إزالة أحداث التقويم (calendar) مثل الأرباح، والتوزيعات، والتقييمات، إلخ، أو الإشارات (signals) مثل نشاط الخيارات، والإيقافات، إلخ، تقوم الخدمة تلقائيًا بإرسال طلبات HTTP POST إلى عنوان الـ webhook الخاص بك مع حمولة البيانات (payload). القدرات الرئيسية:
  • نطاقات قابلة للتهيئة لتغطية بيانات التقويم (calendar) والإشارات (signals) بحيث تستلم فقط البيانات التي تحتاجها
  • عمليات تسليم متطابقة (idempotent) مع ترويسة فريدة X-BZ-Delivery وحقل id في الحمولة لأغراض إزالة التكرار
  • جدول إعادة محاولة متين يتدرج من محاولات سريعة بأسلوب أسي إلى محاولات طويلة الأمد تُجرى كل ساعة
  • تحويلات اختيارية على content لمواءمة الحمولات مع توقعات الأنظمة اللاحقة في سلسلة المعالجة

تسليم طلبات Webhook

تفاصيل طلب HTTP

  • Method: POST
  • Content-Type: application/json
  • User-Agent: Benzinga-Dispatch/v1.0.0 {build-version}
  • Custom Header: X-BZ-Delivery - معرّف UUID فريد خاص بكل محاولة تسليم (مفيد لمنع التكرار)

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

تطبق خدمة Webhook للبيانات آلية قوية لإعادة المحاولة:
  • المرحلة الأسية: 15 محاولة خلال أول 5 دقائق
  • محاولات أسية إضافية: 11 محاولة إضافية عند الحاجة
  • مرحلة الفاصل الزمني الثابت: 12 محاولة في الساعة × 24 ساعة/يوم × 7 أيام (لإعادة المحاولة على المدى الطويل)
  • أقصى مدة انتظار: 5 دقائق بين المحاولات في المرحلة الأسية
  • مهلة الطلب: 30 ثانية لكل طلب

متطلبات الاستجابة

يجب أن تُرجِع نقطة نهاية الـ webhook الخاصة بك أحد رموز حالة HTTP التالية:
  • رموز النجاح (200-202، 204): تشير إلى نجاح عملية التسليم. لن تتم أي محاولات إعادة إرسال.
  • رموز أخطاء العميل (401-403): تشير إلى فشل في المصادقة/التفويض. سيتم إيقاف محاولات إعادة الإرسال فورًا لمنع المزيد من المحاولات الفاشلة.
  • رموز أخرى (4xx، 5xx): ستؤدي إلى محاولات إعادة إرسال وفقًا لسياسة إعادة المحاولة أعلاه.
مهم: يجب أن تستجيب نقطة النهاية الخاصة بك بسرعة (يفضل خلال 30 ثانية) لتفادي انتهاء المهلة. سيقوم المحرك بإعادة المحاولة في حال انتهاء المهلة.

بنية حمولة الـ Webhook

يتضمن كل استدعاء Webhook حمولة JSON بالهيكلية التالية:

حقول الحمولة

الحقول على المستوى الأعلى

  • id (string, UUID): معرّف فريد لتسليم الـ webhook هذا. استخدمه لمنع التكرار.
  • api_version (string): معرّف إصدار واجهة برمجة التطبيقات API. حاليًا "webhook/v1".
  • kind (string): معرّف مسار نوع البيانات. راجع أنواع البيانات المدعومة لجميع القيم المحتملة.

كائن البيانات

  • action (string): نوع إجراء الحدث. القيم الممكنة:
    • "Created": تم إنشاء بيانات جديدة (القيمة الافتراضية لمفاتيح webhook الجديدة)
    • "Updated": تم تحديث البيانات الحالية
    • "Removed": تم حذف البيانات
    • ملاحظة: قد تتلقى مفاتيح webhook القديمة قيماً بحروف صغيرة: "created", "updated", "removed"
  • id (string): معرّف فريد لسجل calendar/signal
  • timestamp (string، ISO 8601): الطابع الزمني عند إنشاء الـ webhook
  • content (object): بيانات calendar أو signal الفعلية. تختلف البنية حسب نوع البيانات (انظر أنواع البيانات المدعومة)

أنواع البيانات المدعومة

تدعم خدمة Webhook الخاصة بالبيانات أنواع التقويم والإشارات التالية:

أنواع بيانات calendar ‏(v2.1)

أنواع بيانات الإشارات (v1)

أنواع بيانات إضافية (v1)

أمثلة على بنية المحتوى

مثال للأرباح

مثال لتوزيعات الأرباح

مثال للتقييمات

مثال على نشاط عقود الخيارات

إجراءات الأحداث

تقوم خدمة webhook للبيانات بإرسال أحداث لثلاثة أنواع من الإجراءات:
  1. Created: يتم إرسال حدث عند نشر بيانات calendar أو بيانات الإشارات الجديدة
  2. Updated: يتم إرسال حدث عند تعديل البيانات الحالية
  3. Removed: يتم إرسال حدث عند حذف البيانات
ملاحظة: يعتمد شكل حقل الإجراء على تكوين الـ webhook لديك:
  • مفاتيح webhook الجديدة: تستقبل إجراءات بحروف كبيرة ("Created", "Updated", "Removed")
  • مفاتيح webhook القديمة (Legacy): تستقبل إجراءات بحروف صغيرة ("created", "updated", "removed")

تصفية المحتوى

يمكن أن يتضمّن تكوين الـ webhook لديك عوامل تصفية للتحكم في البيانات التي تتلقّاها:

خيارات التصفية

  • أنواع البيانات: التصفية حسب أنواع معيّنة من calendar/الإشارات (مثلًا: الأرباح فقط، التقييمات فقط)
  • عوامل التصفية الجغرافية: التحكم في ما إذا كنت ستستقبل:
    • بيانات السوق الأمريكية (AllowUSA)
    • بيانات السوق الكندية (AllowCanada)
    • بيانات السوق الهندية (AllowIndia) - لبيانات WIIMs
  • عامل تصفية التاريخ: استبعاد البيانات التاريخية الأقدم من تاريخ معيّن (MaxHistoricalDate)

التصفية حسب البورصة

تقوم الخدمة تلقائيًا بتصفية البورصات استنادًا إلى إعداداتك الجغرافية:
  • البورصات الأمريكية: NYSE, NASDAQ, AMEX, ARCA, OTC, OTCBB, PINX, PINK, BATS, IEX
  • البورصات الكندية: TSX, TSXV, CSE, CNSX

تحويل المحتوى

يدعم محرك الـ webhook تحويل المحتوى لأنواع بيانات محددة. يتم تطبيق التحويلات بناءً على إعدادات الـ webhook الخاصة بك، وقد تتضمن:
  • إعادة تسمية الحقول
  • تحويل تنسيقات البيانات
  • تصفية/إزالة الحقول

أفضل الممارسات

1. Idempotency

استخدم الحقل id (UUID) في الـ payload لتطبيق خاصية idempotency. خزّن معرّفات التسليم التي جرى معالجتها لتفادي المعالجة المكرّرة.

2. التعامل مع الاستجابة

  • أرجِع 200 OK أو 204 No Content على الفور عند استلام الـ webhook
  • عالِج البيانات بشكل غير متزامن إذا لزم الأمر
  • لا تنفِّذ عمليات طويلة الأمد قبل إرسال الاستجابة

٣. معالجة الأخطاء

  • أرجِع رموز حالة HTTP المناسبة
  • في حالة أخطاء المصادقة (401-403)، تأكّد من ضبط الـ endpoint بشكل صحيح
  • في حالة الإخفاقات المؤقتة، أرجِع رموز حالة من نوع 5xx لتفعيل إعادة المحاولة

4. الأمان

  • استخدم HTTPS لنقطة النهاية الخاصة بالـ webhook
  • نفِّذ آليات المصادقة/التفويض (مفاتيح واجهة برمجة التطبيقات API، رموز الوصول، إلخ)
  • تحقَّق من الترويسة X-BZ-Delivery لمزيد من الأمان

5. المراقبة

  • راقب أزمنة استجابة نقطة النهاية الخاصة بك
  • اضبط تنبيهات لحالات الفشل المتكررة
  • تتبّع ترويسة X-BZ-Delivery لتحديد محاولات التسليم

6. التعامل مع أنواع البيانات

  • تحقق من حقل kind لتحديد نوع البيانات
  • حلّل كائن content وفقًا لبنية نوع البيانات
  • تعامل مع تنسيقات الإجراء المختلفة (أحرف كبيرة مقابل أحرف صغيرة) إذا كنت بحاجة إلى دعم المفاتيح القديمة

مثال لمُعالج Webhook

Python (Flask)

Node.js (Express)

Go

استكشاف الأخطاء وإصلاحها

المشكلات الشائعة

  1. عدم استلام أي webhooks
    • تحقَّق من أن عنوان الـ webhook (URL) مكوَّن بشكل صحيح
    • تأكَّد من أن نقطة النهاية لديك متاحة للعامة
    • تأكَّد من أن مفتاح واجهة برمجة التطبيقات API لديك صالح وفعّال
    • تحقَّق من أن عوامل التصفية لا تستبعد جميع أنواع البيانات
    • تحقَّق من أن عوامل التصفية الجغرافية تطابق البيانات التي تتوقعها
  2. عمليات تسليم مكررة
    • نفِّذ خاصية idempotency باستخدام الحقل id
    • تحقَّق من أزمنة استجابة نقطة النهاية لديك (قد تؤدي الاستجابات البطيئة إلى إعادة المحاولة)
  3. أخطاء مصادقة (401-403)
    • تحقَّق من إعدادات المصادقة لنقطة النهاية لديك
    • تحقَّق من مفاتيح واجهة برمجة التطبيقات API ورموز الوصول
    • ملاحظة: تؤدي أخطاء المصادقة إلى إيقاف إعادة المحاولة فورًا
  4. أخطاء انتهاء المهلة
    • تأكَّد من أن نقطة النهاية لديك تستجيب خلال 30 ثانية
    • عالج البيانات بشكل غير متزامن عند الحاجة
    • أعد استجابة نجاح فورًا ثم عالج البيانات لاحقًا
  5. تنسيق إجراء غير متوقَّع
    • تحقَّق مما إذا كنت تستخدم مفتاح webhook قديمًا (قِيَم الحقل action بحروف صغيرة)
    • حدِّث إلى مفتاح webhook جديد لاستلام قِيَم الحقل action بحروف كبيرة
    • عالِج كلا التنسيقين إذا كنت تدعم عدة عملاء
  6. أنواع بيانات مفقودة
    • تحقَّق من أن تكوين webhook لديك يتضمّن أنواع البيانات المطلوبة
    • تحقَّق من عوامل التصفية الجغرافية (إعدادات US/Canada/India)
    • تأكَّد من أن عوامل تصفية التاريخ لا تستبعد البيانات الحديثة

الدعم

للاستفسارات أو المشكلات المتعلقة بتسليم الـwebhook:

سجل الإصدارات

  • v1.0.0: الإصدار الأولي لخدمة Webhook للبيانات
  • Current: الإصدار الحالي مع تحسين آليات التصفية والتحويل وإعادة المحاولة