API لوحة SMM: دليل ربط موقعك أو بوتك بالخدمات

تبني متجرًا صغيرًا أو بوتًا لبيع خدمات السوشيال ميديا، وتكتشف بعد أسبوعين أنك تقضي يومك في نسخ الروابط ولصقها داخل اللوحة طلبًا بعد طلب. هنا يأتي دور API لوحة SMM: بدل أن تنفذ أنت كل شيء يدويًا، يرسل نظامك الطلب بنفسه ويسأل عن حالته. هذا الدليل يشرح الفكرة بجملة واحدة، ثم تسلسل العمل خطوة بخطوة، ثم طريقة تصميم ربط آمن، وقائمة اختبار، والأخطاء التي تكلّف أصحابها مالًا. لا وعود دخل هنا ولا مبالغة، فقط ما تحتاجه لتبدأ بثقة.

ما هو API لوحة SMM وماذا يفعل؟

API لوحة SMM هو واجهة برمجية تتيح لبرنامجك، سواء كان موقعًا أو بوتًا أو سكربتًا، أن يرسل أوامر إلى اللوحة ويستلم ردودًا منها بصيغة JSON، دون أن تفتح الواجهة وتضغط بيدك. وهذا ما يقصده من يبحث عن ربط موقع بلوحة رشق، ويسميه كثيرون smm panel api أو API سيرفر رشق.

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

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

كيف يعمل التسلسل المعتاد من الخدمات إلى الطلب؟

الطلبات كلها ترسل بطريقة POST، وكل طلب يحمل مفتاحك في معامل اسمه key، ومعه معامل action يحدد ما تريده. الردود تأتي بصيغة JSON. هذا ما توضحه صفحة الـ API، وبعده يتكرر النمط نفسه في كل الإجراءات.

1. جلب الخدمات: الإجراء اسمه services، ويعيد قائمة فيها لكل خدمة رقمها واسمها ونوعها وفئتها وسعرها (rate) وأقل كمية وأعلى كمية، وحقلين يبينان هل تدعم الخدمة التعويض وهل تدعم الإلغاء.
2. إنشاء الطلب: الإجراء اسمه add. أبسط صورة له تحتاج رقم الخدمة والرابط والكمية، ويعيد رقم الطلب.
3. متابعة الحالة: الإجراء status يأخذ رقم الطلب ويعيد الكلفة المحتسبة والعدد عند البداية والحالة والكمية المتبقية والعملة.
4. التعويض: الإجراء refill يأخذ رقم الطلب، وبعده يمكنك السؤال عن حالة التعويض بالإجراء refill_status.
5. الإلغاء: الإجراء cancel يأخذ رقم الطلب.
6. الرصيد: الإجراء balance يعيد رصيدك وعملته.

نصيحة: لا تفترض أن التعويض أو الإلغاء متاحان لكل خدمة. اقرأ الحقلين المخصصين لهما في قائمة الخدمات قبل أن تعرض أي زر لعميلك.

ما أنواع الطلبات التي يدعمها إجراء إنشاء الطلب؟

ليست كل الخدمات تشبه بعضها، ولذلك يقبل إجراء add مجموعات معاملات مختلفة بحسب نوع الخدمة. لا تفترض أن كل خدمة تحتاج رابطًا وكمية فقط.

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

القاعدة العملية: استخدم حقل النوع (type) الذي تعيده قائمة الخدمات لتعرف أي معاملات تطلبها كل خدمة، وابنِ نموذج الإدخال في موقعك بحسب ذلك. وللأسماء الدقيقة للمعاملات ارجع إلى صفحة الـ API ولا تعتمد على الذاكرة.

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

كيف تصمم ربط موقع بلوحة رشق بشكل آمن؟

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

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

وإذا شككت يومًا أن مفتاحك تسرب، فتعامل معه كما تتعامل مع كلمة مرور مكشوفة: غيّره من حسابك فورًا ثم راجع طلباتك الأخيرة. وإذا لم تكن مبرمجًا فلا حرج؛ استعن بمن يعرف إدارة الأسرار قبل أن تضع أموالك في الرصيد.

ماذا تفعل عندما يفشل الطلب أو يكتمل جزئيًا؟

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

الصفحة تقول إن الأخطاء تعاد داخل الرد نفسه في حقل error، ولا تصف شكلًا آخر لأخطاء HTTP. فاكتب كودك بحيث يفحص هذا الحقل في كل رد، ولا يكتفي بنجاح الاتصال.

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

مثال افتراضي: عميل طلب 1000 وتنفذ منها 700. أنت تحاسبه على 700 فقط وتعيد له قيمة 300، وتخبره بذلك برسالة واضحة. الصراحة هنا توفر عليك شكاوى كثيرة.

كيف تتابع الحالات والتعويض والإلغاء دون إرهاق النظام؟

الطريقة الأذكى أن تتابع الحالات على دفعات: تجمع أرقام الطلبات المفتوحة وتسأل عنها في طلب واحد بدل طلب لكل رقم. تتيح صفحة الـ API لإجراءات الحالة والتعويض وحالة التعويض والإلغاء أن تمرر أرقامًا متعددة، بحد أقصى 100 رقم في الطلب الواحد.

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

التعويض

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

الإلغاء

كذلك الإلغاء؛ لا تعد عميلك به إلا للخدمات التي يظهر أنها تدعمه، وتحقق من نتيجة الإلغاء المعادة قبل أن ترد الأموال في نظامك.

كيف تضع أسعارك فوق أسعار الـ API؟

سعر الخدمة في الـ API هو سعر التكلفة الذي تدفعه أنت، وتحدد سعر البيع لعميلك فوقه. اجلب السعر من قائمة الخدمات ولا تثبّته يدويًا، لأن الأسعار قد تتغير ويجب أن يتغير حسابك معها.

مثال افتراضي بأرقام مخترعة للتوضيح فقط: إن كان حقل السعر لخدمة ما 0.40 لكل 1000 وقررت هامشًا بنسبة ثابتة، فاحسب سعر عميلك آليًا في كودك بدل أن تحسبه كل مرة بيدك. وأضف هامشًا صغيرًا إضافيًا يغطي رسوم الدفع وتقلب الأسعار.

• اجعل الهامش رقمًا واحدًا في ملف الإعدادات تغيره دون تعديل الكود.
• أعد جلب قائمة الخدمات دوريًا وخزّنها مؤقتًا بدل أن تجلبها مع كل زائر.
• إذا اختفت خدمة من القائمة فعطّلها في متجرك تلقائيًا.
• راجع التكلفة الفعلية قبل أي حملة ترويج على سعر خاص.

وتذكر أن مستويات الولاء تمنحك خصمًا تلقائيًا كلما زاد إنفاقك الإجمالي، من برونزي 2% إلى أسطوري 12%، فيتحسن هامشك مع الوقت. وللأفكار الأعم عن بناء المشروع كله اقرأ دليل البدء في مشروع سيرفر رشق.

كيف تختبر الربط بطلب صغير قبل الإطلاق؟

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

1. أنشئ حسابًا من صفحة التسجيل واشحن مبلغًا صغيرًا تتحمل خسارته.
2. استدعِ فحص الرصيد أولًا؛ إن عاد رصيدك بشكل صحيح فالمفتاح والاتصال سليمان.
3. اجلب قائمة الخدمات واختر خدمة بسيطة بأقل كمية مسموحة، وحسابك عام.
4. أرسل الطلب، واحفظ الرقم الذي عاد، وتأكد أنه يظهر في سجل طلباتك في اللوحة.
5. تابع الحالة حتى تكتمل، وقارن الكلفة المعادة مع حسابك.
6. جرّب خطأ متعمدًا، مثل رابط خاطئ أو كمية أقل من الحد الأدنى، وانظر كيف يتصرف كودك.
7. إن كانت الخدمة تدعم التعويض، جرّبه مرة واحدة للتأكد من تدفقه.

قائمة الفحص قبل الإطلاق

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

ما الأخطاء الشائعة عند الربط التي تتجنبها؟

أغلب الأعطال تأتي من اختصارات أُخذت في الأسبوع الأول. إليك أكثرها تكرارًا:

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

تنبيه: لا توجد خدمة تضمن نتيجة بنسبة 100%، وللمنصات سياسات بخصوص التفاعل الاصطناعي. اقرأ سياسات كل منصة من صفحاتها الرسمية، واشرح ذلك لعملائك بصراحة.

متى لا تحتاج إلى API أصلًا؟

إن كانت طلباتك بضعة طلبات في الأسبوع فلا تحتاج API لوحة SMM، والأفضل أن تنفذها يدويًا من حسابك. الوقت الذي تقضيه في بناء نظام وصيانته أكبر من الوقت الذي توفره عليك.

القاعدة العملية: لا تبدأ بالربط قبل أن ترى حجمًا ثابتًا من الطلبات يتعبك يدويًا. ابدأ يدويًا لأسابيع، تعلّم أي الخدمات تباع وأين تظهر المشاكل، ثم ابنِ الأتمتة حول ما ثبت نفعه.

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