الويب هوك الواردة والاستدعاءات: المتاجر وستور سيريا والشركاء
مرجع للطلبات التي تستقبلها المنصة: أحداث متاجر سلة وزد وشوبيفاي وووكومرس، وواجهة ستور سيريا القديمة، واستدعاءات شركات الشحن والدفع، مع التحقق وما يتغيّر.
آخر تحديث 22 أكتوبر 2026 · آخر تحقق 22 أكتوبر 2026
الغرض#
تسرد هذه الصفحة الطلبات التي تستقبلها المنصة من أنظمة أخرى: أحداث المتاجر من ووكومرس وشوبيفاي وسلة وزد، وواجهة ستور سيريا القديمة بـ«معرّف الأمان»، واستدعاءات تحديث الحالة من شركات الشحن وبوابات الدفع. وتذكر لكل طلب عنوانه وطريقة التحقق منه وما الذي يتغيّر بسببه. هي مرجع للمطوّرين الذين يبنون موصّلاً أو يصلحون خللاً فيه. أما الإشعارات التي ترسلها المنصة إلى نظامك فتجدها في مقالات الويب هوك الصادرة.
من يحتاجها وما المتطلبات#
- المطوّرون الذين يبنون إضافات للمتاجر أو أنظمة شركاء أو أدوات اختبار. معظم التجار لا يستدعون هذه العناوين أبداً: ربط المتجر من «ربط المتاجر» في لوحة التاجر يضبط كل شيء (ووكومرس وشوبيفاي يسجّلان الويب هوك بنفسيهما، وسلة وزد تعملان عبر تطبيقات المنصة).
- كل العناوين تحت
/apiعلى دومين المنصة، وتقبل JSON ولا تحتاج إلى جلسة متصفح. - لا تُعرض الأسرار (الرموز والمفاتيح وأسرار التوقيع) في هذه الصفحة. الأمثلة تستخدم قيماً بديلة مثل
YOUR_WEBHOOK_TOKENوYOUR_SECRET؛ فأبقِ القيم الحقيقية على خادمك.
نظرة سريعة#
| المصدر | الطلب | طريقة التحقق | ما الذي يتغيّر |
|---|---|---|---|
| ووكومرس | POST /api/stores/woocommerce/{token} |
الرمز في المسار مع X-WC-Webhook-Signature |
يحفظ الطلب ثم ينشئ شحنة عندما يكون الربط نشطاً وإنشاء الشحنات تلقائياً مفعّلاً |
| تطبيق شوبيفاي المخصص | POST /api/stores/shopify/{token} |
الرمز في المسار مع X-Shopify-Hmac-Sha256 |
كما في ووكومرس |
| تطبيق شوبيفاي العام | POST /api/stores/shopify/app |
X-Shopify-Hmac-Sha256 بسر التطبيق |
كما سبق، ويوقف الحدث app/uninstalled الربط مؤقتاً |
| خصوصية شوبيفاي | POST /api/stores/shopify/compliance |
X-Shopify-Hmac-Sha256 بسر التطبيق |
يمسح النسخ المحفوظة من بيانات الزبائن |
| أسعار الشحن عند الدفع في شوبيفاي | POST /api/stores/shopify/rates |
استدعاء من شوبيفاي أثناء إتمام الشراء لطلب سعر التوصيل | يعيد سعر شحن ولا يغيّر شيئاً |
| أحداث تطبيق سلة | POST /api/salla/events |
X-Salla-Signature، أو Authorization مساوية للسر |
يسجّل الحدث؛ التفويض وإلغاء التثبيت يحدّثان الربط؛ وأحداث الطلبات تنشئ شحنات |
| ربط سلة عند التفعيل | POST /api/salla/link |
الترويسة X-DS-Link-Secret |
يربط متجر سلة بتاجر بواسطة كود الربط |
| أحداث زد | POST /api/zid/events |
X-Hook-Secret، أو بيانات HTTP Basic |
يسجّل الحدث؛ وتتحول الطلبات إلى شحنات |
| ستور سيريا (قديم) | /api/parcel/...-with-security و/api/merchant/verify و/api/secret/cheack |
المفتاح في Authorization: Bearer مع X-Platform، أو في جسم الطلب (انظر أدناه) |
ينشئ ويقرأ شحنات صاحب المفتاح |
| LFL Express | POST /api/webhooks/lfl |
X-Signature |
يحدّث الحالة الخارجية للشحنة |
| شركات الشحن الأخرى | POST /api/carriers/webhook/{token} |
طريقة التحقق التي ضبطها مشغّل المنصة للشركة (انظر أدناه) | يحدّث الحالة الخارجية |
| شام كاش | POST /api/payments/shamcash/webhook |
جسم طلب مشفّر | يؤكد الدفعة أو يفشلها |
| Paymera | GET أو POST /api/payments/paymera/callback?ref=... |
تُقرأ الحالة من Paymera | يؤكد الدفعة أو يفشلها |
قواعد تنطبق عليها جميعاً#
- لا CSRF ولا جلسة. هذه المسارات ضمن مجموعة الـ API؛ يكفي المرسل العنوان وطريقة التحقق المذكورة أعلاه.
- ردّ سريع ثم عمل لاحق. تردّ نقاط نهاية المتاجر فوراً (
{"ok":true}، أو{"message":"ok"}في سلة) وتنشئ الشحنة بعد إرسال الرد (عندما يكون الربط نشطاً وإنشاء الشحنات تلقائياً مفعّلاً). وتعيد مهام مجدولة محاولة معالجة كل ما بقي معلّقاً: طلبات المتاجر وطلبات سلة كل 5 دقائق، وأحداث زد كل دقيقة. - رموز الحالة التي يراها المرسل.
200مقبول (حتى للأحداث التي تُتجاهل)،401فشل التحقق،404رمز غير معروف،400حمولة غير مقروءة،500خطأ في المعالجة، وهو ما يدفع المرسل إلى إعادة المحاولة. - سقف الطلبات. يخضع كل مسار تحت
/apiأولاً للمحدِّد العام: 60 طلباً في الدقيقة لكل عنوان IP. أما حدود المسارات الأعلى المكتوبة في الشيفرة (240 و600 وغيرهما) فلا ترفع هذا السقف، لذلك يتلقى المرسل الذي يسلّم أكثر من 60 حدثاً في الدقيقة من عنوان IP واحد الرمز429. راجع مقال حدود الطلبات. - التسليم المتكرر. يُعرَّف طلب المتجر بالربط ورقم الطلب في المتجر، فإذا وصل الحدث نفسه مرتين يُحدَّث الطلب المحفوظ ولا تُنشأ شحنة ثانية. ورقم الفاتورة
invoice_noللشحنة هو أول أربعة أحرف من اسم المنصة بحروف كبيرة، ثم رقم الربط، ثم شرطة، ثم رقم الطلب في المتجر (مثلWOOC12-1001)؛ وشحنات زد تبدأ بـZID-يليها رقم الطلب في زد. - تحقّق من التوقيع على جسم الطلب الخام. تُحسب التواقيع على البايتات كما وصلت تماماً. لا تعِد ترميز الـ JSON قبل فحصه أو تمريره.
منصات المتاجر#
ووكومرس#
عندما يربط التاجر متجره تنشئ المنصة الويب هوك داخل المتجر (الموضوعان order.created وorder.updated) بسرّ عشوائي يُحفظ لهذا الربط. عنوان التسليم هو /api/stores/woocommerce/ يتبعه رمز من 40 حرفاً. ويجب أن يحمل الطلب الترويسة X-WC-Webhook-Signature: ترميز base64 لقيمة HMAC-SHA256 لجسم الطلب بهذا السر. التوقيع الخاطئ أو الناقص يعيد 401 مع {"message":"Invalid signature"}، والرمز غير المعروف يعيد 404 مع {"message":"Unknown store"}.
حالات الطلب: الطلبات الملغاة والمستردّة والفاشلة والمحذوفة تُعتبر ملغاة؛ والطلبات المكتملة تُتخطّى (سبق شحنها)؛ وطلبات الدفع عند الاستلام (payment_method يساوي cod) والطلبات المدفوعة تتحول إلى شحنات، ومبلغ التحصيل هو إجمالي الطلب في حالة cod فقط؛ وبقية الطلبات غير المدفوعة تنتظر تحديثاً لاحقاً.
شوبيفاي#
يستخدم التطبيق المخصص العنوان /api/stores/shopify/{token}. يسجّل الربط الموضوعين orders/create وorders/updated، ويُوقَّع كل طلب في X-Shopify-Hmac-Sha256 (قيمة HMAC-SHA256 لجسم الطلب بترميز base64) بسر التطبيق الذي أدخله التاجر. أما التطبيق العام فله عنوان واحد هو /api/stores/shopify/app ويُوقَّع بسر تطبيق المنصة. يؤخذ المتجر من X-Shopify-Shop-Domain؛ فالمتجر غير المعروف يُتجاهل مع {"ok":true}، والموضوع app/uninstalled يوقف الربط مؤقتاً. وتصل مواضيع الخصوصية الإلزامية إلى /api/stores/shopify/compliance: الموضوع customers/redact يمسح الحمولة المحفوظة واسم الزبون للطلبات المذكورة في الطلب، وshop/redact يفعل ذلك لكل طلبات المتجر ويوقف الربط مؤقتاً ويزيل بيانات اعتماده (وتبقى الشحنات سجلاً للشحن)، أما بقية المواضيع فتُسجَّل فقط. وتردّ أسعار الشحن عند الدفع (/api/stores/shopify/rates) بسعر باسم Delivery Syria فقط إذا كانت دولة الوجهة SY والمحافظة معروفة والربط فعّالاً وله شركة توصيل.
حالات الطلب: الطلبات الملغاة أو التي أُبطلت دفعتها (voided) أو المستردّة تُعتبر ملغاة؛ والطلبات المنفَّذة كلياً أو جزئياً تُتخطّى؛ والطلبات المدفوعة أو المصرَّح بها (authorized) أو المدفوعة جزئياً أو بالدفع عند الاستلام تتحول إلى شحنات؛ والباقي ينتظر الدفع.
سلة#
العنوان POST /api/salla/events هو العنوان الوحيد لتطبيق المنصة في سلة. ويجري التحقق من الطلب بالترويسة X-Salla-Signature (قيمة HMAC-SHA256 لجسم الطلب الخام بترميز سداسي عشري)، أو، عند غيابها، بترويسة Authorization مساوية للسر (مع Bearer أو بدونها). وإذا لم يكن على الخادم سر مضبوط فكل طلب يُرفض بـ 401 مع {"message":"unauthorized"}. وجسم الطلب الذي ليس JSON يعيد 400 مع {"message":"invalid payload"}؛ والنجاح 200 مع {"message":"ok"}؛ وخطأ المعالجة 500، ويبقى حدث الطلب عندها غير معالَج إلى أن تعيد المهمة المجدولة محاولته.
يُسجَّل كل حدث بعد حذف الرموز منه. الحدث app.store.authorize يحفظ رموز المتجر (مشفّرة) ويحدّث ربط المتجر؛ وapp.uninstalled يمسح الرموز ويوقف الربط مؤقتاً؛ والأحداث order.created وorder.updated وorder.status.updated وorder.payment.updated وorder.cancelled تدخل مسار الطلبات؛ وبقية الأحداث تُسجَّل فقط. تُنشأ الشحنة عندما تكون حالة الطلب في سلة under_review أو in_progress ويكون الطلب بالدفع عند الاستلام أو مدفوعاً؛ أما payment_pending والمسودات فتنتظر، والملغاة تُسجَّل ملغاة، وأي حالة أخرى تُتخطّى. وافتراضياً تُؤخذ فقط الطلبات التي تُشحن عبر تطبيق المنصة نفسه؛ ويستطيع مشغّل المنصة إيقاف هذا القيد.
أما POST /api/salla/link فتستدعيه دالة التطبيق في سلة أثناء التفعيل، وليس التاجر. يحتاج الترويسة X-DS-Link-Secret وجسم طلب بصيغة JSON فيه merchant_id (أرقام فقط) وcode، وهو كود الربط الذي يأخذه التاجر من المنصة (صالح 10 دقائق). 401 تعني سراً خاطئاً؛ و422 أن الربط رُفض: رقم متجر غير صالح، أو كود غير صالح أو منتهي، أو تاجر لا يستطيع الربط (الحساب ليس تاجراً نشطاً وموثّقاً، أو لا يوجد مكان استلام نشط، أو الباقة لا تتضمن ربط المتاجر، أو بلغت الباقة حدّ المتاجر)، وتذكر رسالة الرد السبب؛ و200 ربطاً ناجحاً؛ وأي خطأ غير متوقع يعيد 500.
زد#
العنوان POST /api/zid/events (يُقبل مقطع إضافي واحد في المسار) يجب أن يحمل سرّ زد المضبوط: إما أن تساوي الترويسة X-Hook-Secret السر، أو أن يساوي اسم المستخدم وكلمة المرور في HTTP Basic الزوج المضبوط. الفشل يعيد 401 مع {"ok":false}. وعندما يربط التاجر المتجر تشترك المنصة فيه بالأحداث order.create وorder.status.update وorder.payment_status.update.
تخزّن نقطة النهاية الحدث وتردّ بـ {"ok":true}. ثم تحوّل مهمة مجدولة أحداثَ الطلبات إلى شحنات، فتعمل مباشرة بعد الرد وتتكرر كل دقيقة: يجب أن يكون الطلب بالدفع عند الاستلام أو مدفوعاً، وأن يكون المتجر مربوطاً بتاجر اختار شركة توصيل ومكان استلام، وأن يحتوي اسم طريقة الشحن افتراضياً على "delivery syria" (ويستطيع مشغّل المنصة إيقاف هذا القيد). والطلب الإلكتروني غير المدفوع ينتظر حدث الدفع.
ستور سيريا والمنصات التي تعمل بالمفتاح (قديمة)#
هذه هي واجهة «معرّف الأمان» الأقدم التي تستخدمها إضافة ستور سيريا وإضافة ووكومرس القديمة والمنصات المخصصة. بقيت من أجل هذه الجهات؛ فاستخدم واجهة التاجر (Merchant API) في التكاملات الجديدة.
- المفتاح. ينشئه تاجر المنصة في «الويب هوك والـ API» ضمن «مفاتيح الويب هوك» (ستور سيريا، إضافة ووكومرس، سلة، API) أو «منصات مخصصة» (حتى 5، لكل منها قيمة
X-Platformخاصة بصيغةcustom:<name>). يبدأ المفتاح بـsk_. وعندما تُطبَّق الباقات يحتاج توليد مفتاح ستور سيريا أو إضافة ووكومرس أو سلة أو الـ API أو تجديده إلى ميزةstoresفي الباقة (وapiلمفتاح الـ API). - مكان المفتاح. الطلبات
POST /api/parcel/create-with-securityوGET /api/parcel/list-with-securityوGET /api/parcel/tracking-logs/{tracking}تأخذAuthorization: Bearer YOUR_KEYوX-Platformمساوية لنوع المفتاح، ولا تُستخدم ترويسةapiKeyالخاصة بواجهة الجوال. الترويسات الناقصة تعطي401، والمفتاح غير المعروف يعطي403معInvalid credentials. أماPOST /api/merchant/verifyوPOST /api/secret/cheackفيأخذان المفتاح في جسم الطلب كما في الجدول.
| الطلب | الغرض |
|---|---|
POST /api/merchant/verify |
في جسم الطلب security_id (من 10 إلى 255 حرفاً) وplatform (woocommerce أو salla أو storesyria)؛ يعيد رقم التاجر والاسم التجاري ورقم الشركة والأرصدة؛ ويجب أن يتبع الحساب شركة المنصة؛ والمدخلات غير الصالحة تعطي 422، والمفتاح أو المنصة الخاطئان 403 |
POST /api/parcel/create-with-security |
ينشئ شحنة لصاحب المفتاح: hub_id، أو Governorate أو delivery_city لإيجاد الفرع، مع customer_name وcustomer_phone وcustomer_address وcod_amount (أو cod_amount2) وinvoice_no اختياري؛ تكرار invoice_no يعطي 409؛ والرصيد غير الكافي يعيد 200 مع wallet_status بقيمة pending_payment |
GET /api/parcel/list-with-security |
شحنات صاحب المفتاح التي أُنشئت عبر هذه الواجهة بقيمة X-Platform نفسها (وتُطابَق بالحقل invoice_no) مع أرصدة المحفظة؛ per_page من 1 إلى 100 (الافتراضي 10) وvisible بقيمة 0 أو 1 |
GET /api/parcel/tracking-logs/{tracking} |
حالة إحدى شحنات صاحب المفتاح وحالة مزامنتها |
POST /api/secret/cheack |
في جسم الطلب الحقل secret؛ يسرد المحافظات الـ 14 (id وgovernorate وbase_cost وavailable وcode)، حيث base_cost هي أجرة التوصيل لوزن 1 كغ لشركة التاجر، وavailable تكون false عندما يتعذّر احتسابها؛ ويعيد 400 بدون secret و404 للسر غير المعروف (هكذا كُتب اسم المسار) |
وطلبات المحافظات المساعدة مثل GET /api/parcel/governorates موصوفة في مقال نقاط النهاية العامة المساعدة. أما تحديثات الحالة التي ترسلها المنصة إلى ستور سيريا فخارج نطاق هذه الصفحة.
شركات الشحن وبوابات الدفع#
- LFL Express،
POST /api/webhooks/lfl: الترويسةX-Signature(قيمة HMAC-SHA256 لجسم الطلب بترميز سداسي عشري، معsha256=أو بدونها) بالسر المحفوظ للشركة، واسم الحدث فيX-Eventأو في الحقلeventضمن جسم الطلب؛ والأحداثshipment.status_updatedوshipments.createdوshipments.failed. غياب السر المحفوظ يعطي500معwebhook not configured، والتوقيع الخاطئ401معinvalid signature، والـ JSON التالف400. والتسليم المتكرر (نفسdelivery_id، أو جسم طلب مطابق عندما لا يُرسلdelivery_id) يُجاب بـduplicate, already received. ويخزّن تحديث الحالة حالة الشركة على الشحنة وينقل حالة المنصة عبر جدول حالات الشركة؛ ويُتجاهل الحدث الأقدم من الحالة المخزّنة، وتحتفظ الشحنة التي صارت «تم التسليم» أو «فشل التوصيل — راجع للشركة» بحالتها في المنصة. - شركات الشحن الأخرى،
POST /api/carriers/webhook/{token}(و/{account}لحساب التاجر الخاص عند الشركة): الرمز يحدّد الشركة. يختار مشغّل المنصة طريقة التحقق من استدعاءات كل شركة؛ أما حساب التاجر الخاص فيتطلب دائماً توقيع HMAC بالسر الذي حفظه التاجر. الرمز أو الحساب غير المعروف يعطي404، والتحقق الفاشل401معinvalid signature(أو معwebhook secret not configuredإذا لم يكن هناك سر محفوظ)، والحدث المكررduplicate، والشحنة غير المعروفةparcel not foundمع200. - شام كاش،
POST /api/payments/shamcash/webhook(أو/{gateway}): جسم الـ JSON هو{"encData": "..."}، رسالة مشفّرة تفكّها المنصة بالمفتاح السري للبوابة. الرسالة التي يتعذّر فكها أو انتهت صلاحيتها تعطي400، والبوابة غير المعروفة404. الحالة 4 تؤكد الدفعة، و3 تجعلها منتهية، و2 أو 5 تجعلانها فاشلة؛ والمرجع غير المعروف يُجاب بـ200. - Paymera،
/api/payments/paymera/callback?ref=...: تتجاهل المنصة محتوى الطلب وتسأل Paymera عن حالة الدفع الحقيقية، فتأتي الحالة دائماً من Paymera نفسها.GETيعيد الزبون إلى الصفحة المناسبة، وPOSTيردّ بـ{"ok":true}. وتسأل مهمة مجدولة (كل 10 دقائق) البوابة عن الدفعات التي بقيت معلّقة أكثر من 12 دقيقة.
أخطاء شائعة#
- استخدام مفتاح API الخاص بالتاجر على ويب هوك متجر. عناوين المتاجر لها رمزها وتوقيعها، ولا تقبل مفاتيح المنصة
sk_إلا طلبات ستور سيريا. - إعادة ترميز جسم الطلب قبل فحص التوقيع. احسب الـ HMAC على البايتات الخام.
- طلب المتجر لا يتحول إلى شحنة. تحقق من أن ربط المتجر نشط (يُوقَف مؤقتاً بعد إلغاء التثبيت أو عند فقدان الصلاحية) ومن تفعيل إنشاء شحنة تلقائياً لكل طلب للمتجر، ومن اختيار شركة توصيل ومكان استلام للمتجر (يُسجَّل الطلب فاشلاً بملاحظة تبدأ بـ «إعداد المتجر ناقص:»)، ومن أن الطلب مدفوع أو بالدفع عند الاستلام وغير منفَّذ مسبقاً، وفي سلة وزد من أن الزبون اختار شحن المنصة.
- إرسال عدد كبير من الأحداث دفعة واحدة يعيد
429. يُسمح لعنوان IP واحد بـ 60 طلباً في الدقيقة إلى/api. - ويب هوك ووكومرس يدوي بدون سر الربط. لا تستطيع المنصة التحقق منه فتردّ بـ
401.
الحدود والصلاحيات#
- صفحتا ربط المتاجر والويب هوك والـ API مخصصتان لتجار المنصة (يُحوَّل التاجر الذي أنشأته شركة توصيل إلى لوحة التحكم)، وعندما تكون باقات التجار مطبّقة يحتاج ربط ووكومرس أو شوبيفاي أو سلة إلى باقة تتضمن ربط المتاجر.
- تحتاج سلة وزد إلى بيانات تطبيقيهما وأسرارهما مضبوطة على الخادم؛ وبدونها يفشل التحقق.
- تعتمد زد على سرّ مشترك: أبقِه خاصاً كأنه كلمة مرور، وغيّره إذا تسرّب.
- ملاحظة: واجهة ستور سيريا قديمة؛ فاستخدم واجهة التاجر (Merchant API) في التكاملات الجديدة.
API
POST /api/stores/{platform}/{token}POST /api/stores/shopify/appPOST /api/stores/shopify/compliancePOST /api/stores/shopify/ratesPOST /api/salla/eventsPOST /api/salla/linkPOST /api/zid/eventsPOST /api/merchant/verifyPOST /api/parcel/create-with-securityGET /api/parcel/list-with-securityGET /api/parcel/tracking-logs/{track_id}POST /api/secret/cheackPOST /api/webhooks/lflPOST /api/carriers/webhook/{token}POST /api/payments/shamcash/webhookGET /api/payments/paymera/callback