الأتمتة والتكامل عبر واجهة API للوحة

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

ماذا تفعل واجهة API؟

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

العملية	استخدامها
قائمة الخدمات	سحب الأسعار والخدمات
إنشاء طلب	إرسال الطلبات تلقائيا
حالة الطلب	متابعة الإكمال
استعلام الرصيد	تنبيه الشحن التلقائي
طلب التعويض (refill)	طلب تلقائي بعد الانخفاض

من يستخدمها؟

الموزعون. الجمهور الأهم. إن كان للموزع لوحته الخاصة فهو يريد أن يربطك كمزود. وبغياب واجهة API لا يستطيع الربط فيذهب إلى لوحة أخرى.

وكالات الشراء بالجملة. بدلا من إدخال مئة طلب يدويا يرسلونها من جداولهم الخاصة.

العملاء الذين يبنون أتمتة. أصحاب متاجر إلكترونية يريدون تحويل الطلب الوارد من موقعهم إليك مباشرة.

القاسم المشترك بين هذه المجموعات الثلاث أنها أعلى العملاء حجما وأكثرهم انتظاما.

التزم بالصيغة المعيارية

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

الصيغة المعيارية تقوم على مصادقة بالمفاتيح، ونقطة نهاية واحدة، واختيار العملية عبر الوسيط action. حافظ على هذا.

ما يجب مراعاته عند منح API للموزع

1. أعط كل موزع مفتاحا خاصا. يجب أن تكون قادرا على إغلاق مفتاح واحد يسبب مشكلة.
2. ضع حدا للسرعة. الطلبات غير المحدودة في الثانية تبطئ لوحتك.
3. تحقق من الرصيد في جهة الخادم. الطلب الذي لا يكفيه رصيده يجب أن يرفض.
4. اكتب رسائل الأخطاء بوضوح. واجهة تقول "الرصيد غير كاف" بدلا من "حدث خطأ" تقلل طلبات الدعم الواصلة إليك.

أبق الوثائق جاهزة

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

واجهة API تخرج لوحتك من كونها موقعا واحدا إلى بنية تحتية يبني عليها آخرون أعمالهم. وهذا أكثر طرق النمو قابلية للتوسع.