API · البدء

Webhooks

استقبال أحداث Operix لأنظمتك.

مقدمة

Operix تدعم webhooks بطريقتين:

Webhooks واردة — تستقبل POST من أنظمة خارجية وتُشغّل workflow. (راجع POST /api/automation/webhook/:id)
Webhooks صادرة — Operix ترسل POST لـ URL تحدّده عند أحداث معيّنة. تُنفَّذ كـ workflow action عبر http_request.

مثال: استقبال webhook خارجي

عندك workflow في Operix مع triggerType = WEBHOOK. الـ ID هو wf_abc123. أي نظام خارجي يرسل POST لـ:

POST https://operix.operixdigital.com/api/automation/webhook/wf_abc123

الـ body يصبح {{triggerData.body}}، الـ headers تصبح {{triggerData.headers}}.

مثال: إرسال webhook خارجي

داخل workflow، أضف http_request action:

{
  "id": "notify_slack",
  "type": "http_request",
  "config": {
    "method": "POST",
    "url": "https://hooks.slack.com/services/T00/B00/XXX",
    "headers": { "Content-Type": "application/json" },
    "body": {
      "text": "✅ Workflow نجح: {{triggerData.name}}"
    }
  }
}

الأحداث القياسية (للـ webhooks الواردة)

Webhook trigger ليس له schema ثابت — أنت تقرّر الـ payload. لكن أنماط شائعة:

{ "event": "...", "data": {...} } — Zapier-style.
{ "type": "...", "payload": {...} } — Stripe-style.
{ "user": {...}, "action": "..." } — domain-specific.

ثم في الـ condition action: field: triggerData.body.event وتفرّع.

التحقّق من signature (مستقبلاً)

معلومة

حالياً webhooks الواردة لا تتطلب signature. للإنتاج الجدّي، أضف check يدوي في أول عقدة بالـ workflow (HMAC vs {{triggerData.headers.x-signature}}).

الاستجابة المتوقعة

الـ endpoint يستجيب فوراً بـ 200 + { status: "received", runId: "..." }. التنفيذ يحدث في الخلفية على BullMQ.

للحصول على نتيجة الـ workflow، استعلم عن الـ run عبرGET /api/automation/runs/:runId بعد ثوانٍ.