API والتكامل

تكامل API للسوق الإلكتروني

لا يعمل السوق الإلكتروني بمعزل عن غيره أبداً. فالمخزون في ERP، والقيد المحاسبي في خدمة الفوترة الإلكترونية، وحركة الشحنة لدى شركة النقل. ومهمة طبقة API جعل هذه الأنظمة كياناً واحداً عاملاً؛ وإلا لزم فريق ينقل البيانات يدوياً كل يوم.

نقاط نهاية للمنتجات والطلبات والمخزون والبائعين والمحتوى
REST APIنقاط نهاية للمنتجات والطلبات والمخزون والبائعين والمحتوى
إشعار قائم على الأحداث؛ دون حاجة إلى استعلام مستمر
Webhookإشعار قائم على الأحداث؛ دون حاجة إلى استعلام مستمر
أتمتة قائمة على القواعد دون كتابة كود
سير العملأتمتة قائمة على القواعد دون كتابة كود
استيراد مجدول عبر XML وCSV وExcel
نقل جماعياستيراد مجدول عبر XML وCSV وExcel

متى يحلّ التكاملَ API ومتى يحلّه Webhook؟

لا يعمل السوق الإلكتروني بمعزل عن غيره أبداً. فمخزون البائع في نظام ERP الخاص به، والقيد المحاسبي في خدمة الفوترة الإلكترونية، وحركة الشحنة في نظام شركة النقل، والبيانات التسويقية في منصة الإعلانات. ومهمة تكامل API للسوق الإلكتروني هي جعل هذه الأنظمة المنفصلة كياناً واحداً عاملاً؛ وإلا اضطررت إلى تكوين فريق ينقل البيانات يدوياً كل يوم.

وللتكامل اتجاهان، وكلٌّ منهما يتطلب أداة مختلفة. فجلب البيانات من الخارج إلى الداخل (بيانات منتجات البائع ومخزونه، وقائمة أسعار المورّد) يجري عادةً بنقل جماعي مجدول أو باستدعاءات API. أما إرسال المعلومات من الداخل إلى الخارج (أُنشئ طلب جديد، انطلقت الشحنة، فُتِح إرجاع) فينبغي أن يجري عبر webhook. فالتكاملات التي تعمل بالاستعلام المستمر تتأخر وتولّد حملاً لا لزوم له.

والمسألة الثالثة هي المتانة. ففي التكاملات الواقعية لا يستجيب النظام المقابل، أو يُرسَل الحدث نفسه مرتين، أو ينتهي وقت الطلب. ولهذا فإن مفاتيح idempotency وإعادة المحاولة التلقائية وحدود المعدل وطابور الأخطاء ليست زخارف اختيارية بل متطلبات أساسية. وفي PazaryeriSoft تأتي هذه جزءاً من طبقة API.

الوحدات

وحدات جاهزة في طبقة API

REST API والوثائق

نقاط نهاية على أساس الموارد، وصيغة أخطاء متسقة، وترقيم صفحات. ويعمل فريق التكامل على أمثلة للطلبات والاستجابات.

إدارة Webhook

يُعرَّف من اللوحة أي حدث يذهب إلى أي عنوان؛ ويمكن استعراض سجل الإرسال والمحاولات الفاشلة.

إدارة مفاتيح API والنطاقات

مفتاح منفصل لكل تكامل؛ ويُعرَّف على مستوى المفتاح نطاق القراءة والكتابة وقيد عنوان IP.

Idempotency وإعادة المحاولة

ورود الطلب نفسه مرتين لا يُنشئ سجلاً مكرراً؛ وتُعاد محاولة الاستدعاءات الفاشلة بفواصل متزايدة.

حد المعدل والحصة

يُعرَّف حد للطلبات لكل تكامل؛ وعند الاقتراب من الحد يُرَدّ تنبيه في ترويسات الاستجابة.

الاستيراد من XML وCSV وExcel

تُزامَن كتالوجات البائعين والمورّدين بانتظام عبر استيراد مجدول؛ وتُجرى مطابقة الحقول مرة واحدة.

أتمتة سير العمل

تعريف القواعد دون كتابة كود: أرسل إشعاراً عند شرط معيّن، أو أضف وسماً، أو قيّد بائعاً، أو أرسل طلباً إلى خدمة خارجية.

التصدير الجماعي

تصدير بيانات الطلبات والمنتجات والمستحقات لأغراض التقارير ومستودع البيانات.

سجلات الطلبات وطابور الأخطاء

تُسجَّل الاستدعاءات الواردة والصادرة؛ وتتجمّع العمليات الخاطئة في طابور ويمكن إعادة تشغيلها يدوياً.

التحقق من الطلبات الموقّعة

تُوقَّع أجسام webhook؛ فيستطيع الطرف المستقبِل التحقق من أن الطلب صادر عنك فعلاً.

واجهات مستقلة عن المزوّد

تُوصَل مزوّدات الدفع والشحن والفوترة عبر واجهة مشتركة؛ فتغيير المزوّد لا يؤثر في كود التطبيق.

منظومة التطبيقات

تتصل الوحدات الإضافية وتطبيقات الأطراف الثالثة بالمنصة عبر طبقة API نفسها.

النطاق

سطح API وإشعارات الأحداث

على اليمين نقاط النهاية التي يمكنك استدعاؤها من الخارج، وعلى اليسار الأحداث التي يرسلها النظام إليك. ويستخدم معظم التكاملات الاثنين معاً.

سطح API

  • نقاط نهاية للمنتجات والتنويعات والتصنيفات والخصائص
  • تحديث المخزون والأسعار؛ مع دعم التحديث الجماعي
  • إدراج الطلبات وتحديث حالتها وعمليات الإرجاع
  • إدارة البائعين والمتاجر والمنظمات
  • سجلات العملاء والعناوين والمفضلة
  • إدارة المحتوى والحملات والكوبونات
  • مصادقة قائمة على الرموز وصلاحيات على أساس النطاق

إشعارات الأحداث (webhook)

  • أُنشئ الطلب، دُفِع، أُلغِي، فُتِح إرجاع
  • أُنشئ ملصق الشحن، انطلقت الشحنة، تم التسليم
  • نُشِر المنتج، رُفِض، نفد المخزون
  • اعتُمِد طلب انضمام البائع أو عُلِّق
  • نشأت المستحقات، اعتُمِد طلب السحب
  • التحقق من المصدر عبر جسم طلب موقّع
  • إعادة محاولة تلقائية بفواصل متزايدة عند فشل الإرسال
السيناريوهات

التكاملات الستة الأكثر إنشاءً

تمضي كلها عبر طبقة API نفسها؛ ولا يختلف إلا اتجاه البيانات والمُطلِق.

مزامنة ERP والمخزون

تنعكس على المنصة بيانات المخزون والأسعار المتغيّرة في نظام البائع عبر نقل مجدول أو استدعاء API؛ وعند إنشاء طلب يصل إلى ERP عبر webhook.

الفوترة الإلكترونية والمحاسبة

تُنقَل فواتير العمولة وسجلات المستحقات إلى خدمات مثل Paraşüt وBirFatura. وتُنشَأ سجلات المطابقة تلقائياً في جانب المحاسبة.

أنظمة الشحن واللوجستيات

يمضي إنتاج الملصقات وتحديثات الحالة عبر تكاملات شركات النقل؛ وتُقيَّد حركات الشحنة على الطلب تلقائياً.

التسويق والتحليلات

تُنقَل بيانات الطلبات والمنتجات إلى منصات الإعلان وأدوات التحليلات؛ وتُحدَّث تدفقات المنتجات (feed) بانتظام.

الإدراج في أسواق خارجية

يمكن نقل الكتالوج الموجود في منصتك إلى قنوات خارجية؛ ويُصمَّم تزامن الطلبات والمخزون ليعمل باتجاهين.

واجهة مخصصة واستخدام headless

يمكنك كتابة واجهتك الخاصة واستخدام المنصة كطبقة بيانات فقط؛ ويستهلك تطبيق الجوال واجهة API نفسها.

الأسئلة الشائعة

الأسئلة الشائعة

أكثر الأسئلة تكراراً لدى فرق التكامل.

كلٌّ منهما لاتجاه مختلف. فلجلب البيانات من الخارج إلى الداخل (بيانات منتجات البائع ومخزونه، وقائمة أسعار المورّد) تُستخدَم استدعاءات API أو نقل جماعي مجدول. أما لإرسال المعلومات من الداخل إلى الخارج (أُنشئ طلب جديد، انطلقت الشحنة، فُتِح إرجاع) فالأداة الصحيحة هي webhook. وحلّ ذلك بالاستعلام المستمر يولّد تأخيراً وحملاً لا لزوم له؛ أما الإشعار القائم على الأحداث فيزيل المشكلتين معاً.
لا. يُستخدَم مفتاح idempotency في عمليات الكتابة؛ فالطلب الثاني الوارد بالمفتاح نفسه لا يُنشئ سجلاً جديداً، بل يُرجِع نتيجة العملية الأولى. وفي جانب webhook أيضاً يُنصَح بأن يتحقق النظام المستقبِل من معرّف الحدث لأنه قد يُرسَل مجدداً. وهذا يجعل عمليات إعادة الإرسال — التي لا مفر منها في التكاملات الواقعية — غير ضارة.
تُعاد محاولة إرسال webhook الفاشلة تلقائياً بفواصل متزايدة. وعند استنفاد المحاولات يتجمّع السجل في طابور الأخطاء ويمكن إعادة تشغيله يدوياً من اللوحة. ولأن الاستدعاءات الواردة والصادرة مسجّلة، يمكن لاحقاً فحص أي طلب ومتى وبأي استجابة انتهى؛ وتُحَلّ معظم مشكلات التكامل عبر هذه السجلات خلال دقائق.
يُولَّد مفتاح منفصل لكل تكامل. ويُعرَّف على مستوى المفتاح نطاق القراءة والكتابة؛ فمثلاً يُمنَح تكامل التقارير صلاحية قراءة فقط. ويمكن اختيارياً إضافة قيد على عنوان IP، ويمكن إلغاء المفتاح في أي لحظة. وبذلك فإن اختراق تكامل واحد لا يؤثر في النظام كله بل في نطاقه هو فقط.
نعم، يُعرَّف حد للطلبات لكل تكامل. وعند الاقتراب من الحد تُرَدّ بيانات الحصة المتبقية في ترويسات الاستجابة، فيستطيع جانب العميل إبطاء نفسه. وننصحك في العمليات الجماعية باستخدام نقاط نهاية التحديث الجماعي أو الاستيراد المجدول بدل الاستدعاء الفردي؛ فهو أسرع ولا يُرهق الحصة.
نعم، ومحرّر سير العمل موجود لهذا الغرض. تعرّف قواعد مكوّنة من شروط وإجراءات: أرسل إشعاراً في حالة معينة، أو ضع وسماً على الطلب، أو قيّد بائعاً، أو أرسل طلباً إلى خدمة خارجية. وبهذه الطريقة يُحَلّ جزء كبير من التكاملات البسيطة دون الحاجة إلى مطوّر؛ ولا يُحتاج إلى API إلا في السيناريوهات الأعقد.
نعم. يستطيع البائعون ربط أنظمة ERP أو المخزون الخاصة بهم عبر API، أو إعداد استيراد مجدول بصيغ XML أو CSV أو Excel. وتُجرى مطابقة الحقول مرة واحدة عند التركيب الأول، وتستخدم عمليات النقل اللاحقة القالب نفسه. وتقصّر المطابقة المدعومة بالذكاء الاصطناعي زمنَ ربط الكتالوجات ذات الصيغ المختلفة.

لنخطّط معاً لتكاملاتك

لنستخرج الأنظمة التي ستُوصَل واتجاهات البيانات والمُطلِقات.

REST API + Webhook · أتمتة سير العمل · دعم على مدار الساعة