توقف عن الدفع لمن يعيد كتابة البيانات.
إن كان شخص ينسخ الأرقام نفسها بين نظامين كل أسبوع، فذلك الشخص هو التكامل لديك. نبني الاتصال، ونبني واجهات API تستطيع فرق أخرى العمل بها.
نبني واجهات API ونربط الأنظمة التي ينبغي أن تتحدث أصلاً: المحاسبة، والمتجر الإلكتروني، وبوابات الدفع مثل QPay وTap، والمستودع، ونظام العملاء. موثّقة، بإصدارات واضحة، ومبنية لتتعطل بأمان حين يتوقف الطرف الآخر، فلا يضيع سجل واحد. نتحقق مما يدعمه كل نظام قبل أن نعد بشيء.
آخر تحديث نوفمبر 2026
العطل المكلف هو العطل الصامت.
كل تكامل يتعطل في النهاية. المهم هو: هل يعلم به أحد؟
التكاملات تتعطل. السؤال هو هل تتعطل بصمت.
سيتوقف النظام الآخر، أو يغيّر شكل استجابته، أو يبدأ بتحديد عدد طلباتك. هذا ليس خطراً تصمم لتتجنبه، بل يقين تصمم له.
التكامل المبني بسوء يتعطل بصمت: تتوقف مزامنة الطلبات ولا يلاحظ أحد حتى يشتكي عميل. والمبني جيداً يعيد المحاولة، ويضع الطلبات في طابور، وينبّه شخصاً، ولا يخسر سجلاً أبداً.
والمبدأ نفسه للواجهات التي تنشرها أنت. إن احتاج مطور آخر أن يسألك سؤالاً ليستخدمها، فالوثائق هي المنتج، وهي لم تكتمل بعد.
ما نبنيه.
واجهات REST وGraphQL
متسقة، بإصدارات، وموثّقة بما يكفي ليستخدمها أحد دون أن يسألك كيف تعمل.
وثائق هي المنتج
أمثلة حقيقية، واستجابات خطأ حقيقية، وشيء يستطيع المطور تجربته في المتصفح.
تكاملات بطابور وإعادة محاولة
لا يضيع شيء حين يكون الطرف الآخر غير متاح. هذا معظم ما يعنيه التكامل الجيد.
الربط مع المحاسبة
الطلبات والفواتير تتدفق إلى حساباتك دون أن يعيد أحد كتابتها.
بوابات الدفع
بما فيها المحلية التي تعمل فعلاً في الخليج وباكستان: QPay وTap في قطر، وmada في السعودية.
Webhooks كما ينبغي
موقّعة، لا تتأثر بالتكرار، وتُعاد محاولتها. استقبالاً، وإرسالاً إلى عملائك.
مراقبة وتنبيهات
تسمع عن مزامنة فاشلة منا، لا من عميل بعد ثلاثة أيام.
النقل بين الأنظمة
نقل البيانات من منصة قديمة، مطابقةً مع المصدر قبل أن يُطفأ أي شيء.
كيف تتعطل التكاملات فعلاً.
كل واحدة من هذه حدثت لأحد ما. الفرق هو هل توقّعها البناء.
| ما يحدث | مبني بسوء | مبني كما ينبغي |
|---|---|---|
| النظام الآخر متوقف | تضيع السجلات بصمت | في طابور، تُعاد المحاولة، لا يضيع شيء |
| تغيّر شكل استجابته | ينهار، أو يكتب بيانات خاطئة | يلتقطه التحقق، ويُرفع تنبيه |
| بلغت حد الطلبات | تسقط الطلبات | يتمهّل ثم يستأنف |
| أُرسل السجل نفسه مرتين | طلب مكرر | لا تكرار، بفضل عدم التأثر بالتكرار (idempotency) |
| فشلت مزامنة في الثانية فجراً | تعرف من عميل | يصل تنبيه إلى فريقك |
| أُوقف إصدار واجهته | ينكسر دون إنذار | إصدارات مراقبة، ومخطط لها |
ما ربطناه.
أنظمة دورة حياة البطاقات لأكبر مقسم مدفوعات مشترك في باكستان. تكامل على نطاق حقيقي.
صفحة دفع لشركة تقنية مالية باكستانية، في الإنتاج منذ أكثر من أربع سنوات.
بوابة دفع وفوترة في قطر، بُنيت من فكرة العميل إلى منتج يعمل.
نعرف أي مزودي الدفع يعملون فعلاً في هذه الأسواق، وأيهم لا يعمل.
متى تحتاج هذا.
أحدهم يعيد إدخال البيانات كل أسبوع
أوضح حالة ممكنة. احسب الساعات، وغالباً ما يبرر البناء نفسه سريعاً.
عملاؤك يريدون الربط معك
إن طلب المشترون الكبار واجهة API، فغيابها يكلّفك صفقات.
تكاملك الحالي يتعطل باستمرار
بُني غالباً دون إعادة محاولة أو تنبيهات. كثيراً ما تكون إعادة بنائه أرخص من الاستمرار في ترقيعه.
لا تشترِ هذا إذا كان النقل اليدوي دقائق في الشهر
إن كانت البيانات تنتقل مرة في الشهر وتستغرق ربع ساعة، فاستيراد جدول يكفيك ولن يسترد التكامل كلفته. وإن لم يطلب أحد من عملائك واجهة API، فبناؤها الآن سابق لأوانه. سنقول لك ذلك.
كيف نعمل.
نرسم ما يتحرك وإلى أين
أي بيانات، وفي أي اتجاه، وكم مرة، وماذا يحدث اليوم حين يفشل ذلك.
نتحقق مما يدعمه الطرف الآخر
قبل أن نعد بشيء. بعض الأنظمة لها واجهات ممتازة، وبعضها لا يملك إلا تصدير ملف CSV.
نصمم للفشل
طوابير، إعادة محاولة، عدم تأثر بالتكرار، تنبيهات. تُقرَّر مسبقاً لا بعد أول حادثة.
نبني ونختبر على بيانات حقيقية
في بيئة تجريبية حيث توجد، وبحذر مع بيئة الإنتاج حيث لا توجد.
نشغّل الطريقتين معاً
التكامل الجديد إلى جانب العمل اليدوي حتى تتطابق الأرقام. ثم تنتقل.
نراقب ونسلّم
تنبيهات تصل إلى فريقك، ووثائق، والكود في مستودعك.
التقنيات.
واجهات API والتكامل
7 أسئلة مع إجاباتها. لديك سؤال آخر؟ تواصل معنا.
إن كانت له واجهة API، فغالباً نعم. وإن لم تكن، فهناك عادةً طرق أخرى: تصدير ملف على جدول زمني، أو اتصال بقاعدة البيانات، أو أتمتة الشاشة كملاذ أخير. نتحقق مما تدعمه أنظمتك تحديداً قبل أن نعد بشيء، لأن الجواب الصادق يختلف كثيراً بين المورّدين.