الجوانب التقنية
معيار SMM Panel API v2: الدليل الكامل
آخر تحديث: ، من إعداد فريق تحرير PanelCompare، مدة القراءة 5 دقائق
ما SMM Panel API v2؟
إنها نقطة POST واحدة، على /api/v2 بحكم العرف، تستقبل جسمًا بصيغة application/x-www-form-urlencoded وتعيد JSON. المصادقة معامل key داخل الجسم لا في الترويسة. ولا تفاوض على الإصدارات، ولا توقيع للطلبات، ولا nonce (تم التحقق من المواصفة على justanotherpanel.com/api، 2026-09-06).
نشأت المواصفة مع سكربتات اللوحات المهيمنة، ونُسخت على نطاق واسع حتى صارت المعيار الفعلي للقطاع. وهذه الحقيقة تقف خلف كل شيء تقريبًا في هذه السوق: يمكن إطلاق لوحة في عصر يوم واحد بتوجيه سكربت إلى API مزوّد، ولهذا توجد آلاف اللوحات، ولهذا تبقى الفروق بينها ضئيلة.
المفتاح سرّ طويل الأمد لحامله
لأن مفتاح API ينتقل داخل جسم الطلب دون توقيع أو nonce أو طابع زمني، فلا حماية في المواصفة من إعادة الإرسال ولا انتهاء لصلاحية المفتاح. أي شخص يملك المفتاح يستطيع صرف رصيدك وقراءة كل رابط طلبت عليه. غيّر المفتاح بعد ربط أي أداة خارجية.
ما الإجراءات التي يوفرها API؟
| الإجراء | المعاملات | ما يعيده |
|---|---|---|
| services | key، action | مصفوفة من عروض قائمة الخدمات: service، name، type، category، rate، min، max، refill، cancel |
| add | key، action، service، link، إضافة إلى معاملات خاصة بنوع الطلب | رقم الطلب الجديد (id) |
| status | key، action، order | charge، start_count، status، remains، currency |
| status (متعدد) | key، action، orders (مفصولة بفواصل، 100 كحد أقصى) | كائن مفاتيحه أرقام الطلبات |
| refill | key، action، order (أو orders مفصولة بفواصل) | رقم طلب تعويض، أو مصفوفة من أزواج الطلب/التعويض |
| refill_status | key، action، refill (أو refills مفصولة بفواصل) | حالة طلب التعويض |
| cancel | key، action، orders (مفصولة بفواصل) | نتيجة الإلغاء لكل طلب |
| balance | key، action | balance وcurrency |
المصدر: مواصفة SMM Panel API v2، تم التحقق منها على justanotherpanel.com/api، 2026-09-06.
لاحظ أنه لا يوجد إجراء multi_status مستقل في المواصفة المعيارية. الاستعلام عن حالة عدة طلبات هو إجراء status نفسه مع معامل orders بصيغة الجمع، بحد أقصى 100 رقم في الطلب الواحد، وهي تفصيلة يتعثر بها معظم من يبنون أول ربط.
كيف يبدو الطلب والرد فعلًا؟
POST /api/v2
Content-Type: application/x-www-form-urlencoded
key=YOUR_KEY&action=services
// 200 OK
[
{
"service": 1,
"name": "Followers",
"type": "Default",
"category": "First Category",
"rate": "0.90",
"min": "50",
"max": "10000",
"refill": true,
"cancel": true
}
]POST /api/v2
key=YOUR_KEY&action=add&service=1&link=https://example.com/p&quantity=1000
// 200 OK
{ "order": 23501 }
POST /api/v2
key=YOUR_KEY&action=status&order=23501
// 200 OK
{
"charge": "0.27819",
"start_count": "3572",
"status": "Partial",
"remains": "157",
"currency": "USD"
}خانة rate هي السعر لكل 1000 بعملة الحساب، وتصل نصًا لا رقمًا. قوائم الخدمات الفعلية تضم بين 3,000 و8,000 عرض، فاستدعاء services ردّ واحد كبير لا ردّ مقسّم إلى صفحات.
ما المزالق التي تُفشل أول ربط برمجي؟
- الأخطاء تعود عادةً برمز HTTP 200. في معظم اللوحات يعود الطلب الفاشل بـ200 وفي جسمه كائن خطأ، وبعضها يردّ على المفتاح الخاطئ بـ401 مع صيغة JSON نفسها، فلا يمكن الاعتماد على رمز الحالة، وعلى كل عميل أن يحلّل الجسم ليكتشف الفشل.
- الأرقام تصل نصوصًا. rate وmin وmax وcharge وstart_count وremains كلها نصوص بين علامتي تنصيص، ومقارنتها رقميًا دون تحويل تعطي نتائج خاطئة بصمت.
- الاستعلام عن حالة عدة طلبات هو المعامل بصيغة الجمع، لا إجراء مستقل، وحدّه الأقصى 100 رقم.
- كمية التسليم التدريجي لكل دفعة. استدعاء add مع runs=10 يسلّم quantity × 10 ويخصم ثمنها.
- أرقام الخدمات خاصة بكل لوحة وقابلة للتغيير. تستطيع اللوحة تحويل رقم خدمة إلى مزوّد أصلي آخر، فتبدأ الأرقام المحفوظة لديك بالدلالة على شيء آخر بصمت.
- إجراءا refill وcancel لا يعملان إلا حيث يعلن عرض الخدمة عنهما، وcancel عادةً قبل بدء التسليم فقط.
ما المعاملات التي يحتاجها كل نوع طلب؟
كل استدعاء add يحتاج service وlink. أما ما يحتاجه غير ذلك فتحدده خانة type في عرض الخدمة، والمتطلبات لا يمكن تخمينها. وهذا الجدول هو القائمة كاملة.
| نوع الطلب | المعاملات الإضافية |
|---|---|
| Default / Drip-feed | quantity، runs (اختياري)، interval (اختياري، بالدقائق) |
| Custom Comments | comments (قائمة، كل تعليق في سطر) |
| Custom Comments Package | comments |
| Mentions (قائمة مستخدمين / وسم / قائمة مخصصة) | quantity، usernames، hashtags |
| Mentions Hashtag | quantity، hashtag (الحسابات التي يُشار إليها تُجمع من الوسم) |
| Mentions User Followers | quantity، username (الحسابات التي يُشار إليها تُجمع من متابعي ذلك المستخدم) |
| Mentions Media Likers | quantity، media (رابط) |
| Comment Likes | quantity، username |
| Comment Replies | username، comments |
| Poll | quantity، answer_number |
| Subscriptions | username، min، max، posts (اختياري)، delay، expiry (اختياري)، old_posts (اختياري) |
| Invites from Groups | quantity، groups (كل مجموعة في سطر) |
| Package | link فقط؛ الكمية ثابتة |
| Web Traffic | quantity، country، device، type_of_traffic، google_keyword أو referring_url |
المصدر: مواصفة SMM Panel API v2، تم التحقق منها على justanotherpanel.com/api، 2026-09-06.
كيف تبني ربطك البرمجي عليه؟
- 1.تعامل مع كل رد على أنه بلا أنواع محددة. حلّل الجسم أولًا، وابحث عن مفتاح error، ثم حوّل النصوص الرقمية صراحةً.
- 2.احفظ رقم الخدمة لدى اللوحة إلى جانب خدمتك المعيارية، وأعد مزامنة قائمة الخدمات وفق جدول، حتى تكتشف الرقم الذي حُوّل إلى مزوّد آخر بدل أن تفترض ثباته.
- 3.اجمع الاستعلام عن الحالات في معامل orders بصيغة الجمع، على دفعات من 100، بدل طلب لكل أمر شراء.
- 4.تعامل مع حالة «جزئي» على أنها نتيجة أصيلة لا خطأ، فهي تأتي مع رقم المتبقي وإعادة تلقائية للقيمة إلى الرصيد.
- 5.لا تسجّل جسم الطلب في السجلات أبدًا، فمفتاح API بداخله.
- 6.غيّر المفاتيح وفق جدول، وبعد كل تغيير في ربط مع طرف خارجي.
ماذا يكشف API عن اللوحة؟
أكثر مما يكشفه النص التسويقي. فتح /api/v2 دون مفتاح يعيد ردّ خطأ سليمًا إن كانت هناك نقطة متوافقة مع API v2، أما ردّ 404 فينقض ادعاء اللوحة بأن لديها API، وهذا فحص سريع وموضوعي يستطيع أي شخص إجراءه.
وهو أيضًا الطريقة الوحيدة القابلة للتوسع لجمع أسعار قابلة للمقارنة. معظم اللوحات تحجب قائمة الخدمات خلف التسجيل ولا تنشر علنًا إلا نصوصًا تسويقية، فاستخلاص الصفحات العامة يغطي أقلية من السوق. أما تسجيل حساب واستدعاء إجراء services فيعيد قائمة الخدمات كاملة بصيغة JSON منظّمة في طلب واحد، وبهذه الطريقة يبني PanelCompare مؤشر الأسعار.
إجابات سريعة
ما SMM Panel API v2؟
SMM Panel API v2 نقطة POST واحدة، على /api/v2 بحكم العرف، تستقبل معاملات مرمّزة كنموذج وتعيد JSON، وفيها إجراءات services وadd وstatus وrefill وrefill_status وcancel وbalance. تطبّقها كل اللوحات تقريبًا، فعميل برمجي واحد يعمل مع المئات منها.
كيف أصادق على API لوحة SMM؟
بمعامل key داخل جسم الطلب. لا مصادقة في الترويسة، ولا توقيع للطلبات، ولا nonce، فالمفتاح سرّ طويل الأمد لحامله، وينبغي تغييره بعد أي تغيير في ربط مع طرف خارجي.
لماذا يعيد API الرمز 200 عند الأخطاء؟
لأن المواصفة لا تستخدم رموز حالة HTTP استخدامًا ذا معنى. الأخطاء تعود عادةً برمز HTTP 200 وفي الجسم كائن خطأ، وبعض اللوحات تستخدم 401 مع الجسم نفسه للمفتاح الخاطئ، فعلى كل عميل أن يحلّل جسم الرد ليكتشف الفشل.
كيف أستعلم عن حالة طلبات كثيرة دفعة واحدة؟
استخدم إجراء status نفسه مع معامل orders بصيغة الجمع، يحمل حتى 100 رقم طلب مفصولة بفواصل. لا يوجد إجراء multi_status مستقل في المواصفة المعيارية.
كل رقم هنا منسوب إلى مصدره ومؤرخ
الأسعار في هذه السوق تتغيّر أسبوعيًا، فالرقم الذي لا تاريخ لرصده رقم للزينة. وحيث يذكر هذا الدليل رقمًا، يسمّي مصدره ومتى تحققنا منه. وإن كان أحدها خاطئًا، فإجراء التصحيح المشروح في صفحة «من نحن» يلتزم بالرد خلال يومي عمل، وتُنشر التصحيحات مع ملاحظة مؤرخة بدل أن تُعدَّل بصمت.