هل ترسل هذه الأداة مفتاح API الخاص بي إلى خوادمكم؟

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

لماذا يفشل الطلب بخطأ في الشبكة؟

في أغلب الأحيان بسبب CORS. صُمّمت واجهات API للوحات للاتصال من خادم إلى خادم، فهي لا ترسل ترويسة Access-Control-Allow-Origin التي يشترطها المتصفح قبل أن يسلّم الصفحة ردًّا قادمًا من نطاق آخر، ولذلك يتجاهل المتصفح الرد مع أن الطلب وصل في الغالب. تكتشف الأداة ذلك وتعطيك أمر curl مكافئًا لتشغّله من الطرفية على جهازك، حيث لا تنطبق أي سياسة CORS.

ما القاسم المشترك بين واجهات API للوحات؟

أكثر مما تتوقع، لأن السوق تعمل على عدد قليل من برامج اللوحات. الشكل المعتاد نقطة اتصال واحدة من نوع POST تستقبل مفتاحًا وإجراءً ومعاملات ذلك الإجراء كحقول نموذج مُرمَّزة (form-encoded)، وتعيد JSON. والإجراءات المعتادة هي services وbalance وadd وstatus وrefill. أما ما لا ينتقل أبدًا من لوحة إلى أخرى فهو أرقام الخدمات (service IDs): فهي خاصة بكل لوحة، ولذلك ينكسر أي تكامل يثبّتها في الشيفرة عند الانتقال.

هل من الآمن اختبار الإجراء «add»؟

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

أداة اختبار API للوحات SMM

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

أرسل طلبًا تجريبيًا

الرد

لم يُرسل شيء بعد. ينتقل الطلب مباشرة من هذا التبويب إلى اللوحة. افتح تبويب Network في متصفحك وسترى طلبًا واحدًا فقط، إلى نطاق اللوحة، ولا شيء إلى نطاقنا.

أمر curl المكافئ

curl -s -X POST 'https://your-panel.example/api/v2' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'key=YOUR_API_KEY&action=services'

كُتب المفتاح هنا كعنصر نائب عن قصد. ضع مفتاحك في الطرفية حتى لا ينتهي به الأمر في لقطة شاشة.

أي اللوحات في المؤشر توفر واجهة API؟

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

جُمعت البيانات من 112 لوحة في 30 سبتمبر 2026فحوص التشغيل على مدى 30 يومًا

لوحات توفر واجهة API للطلبات، مرتبة حسب مدة التشغيل خلال 30 يومًا.
اللوحة	مدة التشغيل، 30 يومًا	وسيط الاستجابة	الثقة	لوحات فرعية
ReliableSMMreliablesmm.com	100.0‎%‎	344 ms	82، ثقة عالية	لا
Likeolikeo.net	100.0‎%‎	328 ms	78، راسخة	نعم
ApiSMMapismm.com	100.0‎%‎	313 ms	76، راسخة	نعم
SmmCheapsmmcheap.com	100.0‎%‎	388 ms	76، راسخة	نعم
YtResellersytresellers.com	100.0‎%‎	361 ms	80، راسخة	لا
SMMGosmmgo.io	100.0‎%‎	284 ms	84، ثقة عالية	لا
Xmediaxmediasmm.in	100.0‎%‎	237 ms	84، ثقة عالية	لا
SMMValysmmvaly.com	100.0‎%‎	344 ms	84، ثقة عالية	لا
8CSN8csn.com	100.0‎%‎	279 ms	62، راسخة	نعم
SMM Brightsmmbright.com	100.0‎%‎	259 ms	75، راسخة	لا
WorldOfSMMworldofsmm.com	100.0‎%‎	366 ms	84، ثقة عالية	لا
Marketerummarketerum.com	100.0‎%‎	334 ms	84، ثقة عالية	لا
GodOfPanelgodofpanel.com	100.0‎%‎	378 ms	76، راسخة	نعم
Rezz SMM Panelrezzsmmpanel.com	100.0‎%‎	282 ms	80، راسخة	لا
SMMCostsmmcost.com	100.0‎%‎	385 ms	70، راسخة	نعم
SMMGensmmgen.com	100.0‎%‎	1,016 ms	84، ثقة عالية	لا
SMM Panel Providesmmpanelprovide.com	100.0‎%‎	295 ms	76، راسخة	نعم
HyperPanelhyperpanel.in	100.0‎%‎	229 ms	70، راسخة	نعم
YoYoMediayoyomedia.com	100.0‎%‎	218 ms	73، راسخة	لا
HeySMMResellerheysmmreseller.com	100.0‎%‎	349 ms	76، راسخة	لا

كيف يبدو طلب API للوحة SMM؟

لأن السوق تعمل على عدد قليل من برامج اللوحات، فإن شكل الطلب شبه موحّد: نقطة اتصال واحدة من نوع POST، وحقول نموذج مُرمَّزة، ورد بصيغة JSON. يحدد المفتاح الحساب، ويسمّي الإجراء العملية، وبقية الحقول هي معاملات الإجراء. والإجراءات التي ستجدها في كل مكان تقريبًا هي services وbalance وadd وstatus وrefill.

ثلاثة أمور تختلف بما يكفي لكسر أي تكامل، ولا يُوثَّق أيٌّ منها بشكل متسق. أولها حدود معدل الطلبات، التي تفرضها معظم اللوحات دون أن تنشرها. وثانيها معالجة الأخطاء: بعض اللوحات تعيد رموز أخطاء HTTP، وكثير منها يعيد 200 مع مفتاح error في متن الرد، فاعتبر الرمز 200 دليلًا على أن «الخادم أجاب» لا على أن «الطلب نجح». وثالثها أرقام الخدمات، وهي خاصة بكل لوحة وقد تتغير حين يُعاد بناء قائمة الخدمات، ولذلك يحتاج أي تكامل يخزّنها إلى مطابقة دورية مع الإجراء services بدل خريطة ثابتة في الشيفرة.

أسئلة شائعة

هل ترسل هذه الأداة مفتاح API الخاص بي إلى خوادمكم؟: لا. يرسل متصفحك الطلب مباشرة إلى نقطة الاتصال الخاصة باللوحة. لا يوجد خلف هذه الصفحة معالج مسارات ولا وسيط ولا أي تسجيل. ويمكنك التأكد من ذلك في تبويب Network في أدوات المطوّر، حيث سترى طلبًا واحدًا فقط، إلى نطاق اللوحة نفسها. فمفتاح API للوحة يستطيع إنفاق رصيد مشحون، ولا شأن لموقع مقارنة بالاحتفاظ به ولو أثناء مروره.
لماذا يفشل الطلب بخطأ في الشبكة؟: في أغلب الأحيان بسبب CORS. صُمّمت واجهات API للوحات للاتصال من خادم إلى خادم، فهي لا ترسل ترويسة Access-Control-Allow-Origin التي يشترطها المتصفح قبل أن يسلّم الصفحة ردًّا قادمًا من نطاق آخر، ولذلك يتجاهل المتصفح الرد مع أن الطلب وصل في الغالب. تكتشف الأداة ذلك وتعطيك أمر curl مكافئًا لتشغّله من الطرفية على جهازك، حيث لا تنطبق أي سياسة CORS.
ما القاسم المشترك بين واجهات API للوحات؟: أكثر مما تتوقع، لأن السوق تعمل على عدد قليل من برامج اللوحات. الشكل المعتاد نقطة اتصال واحدة من نوع POST تستقبل مفتاحًا وإجراءً ومعاملات ذلك الإجراء كحقول نموذج مُرمَّزة (form-encoded)، وتعيد JSON. والإجراءات المعتادة هي services وbalance وadd وstatus وrefill. أما ما لا ينتقل أبدًا من لوحة إلى أخرى فهو أرقام الخدمات (service IDs): فهي خاصة بكل لوحة، ولذلك ينكسر أي تكامل يثبّتها في الشيفرة عند الانتقال.
هل من الآمن اختبار الإجراء «add»؟: هذا الإجراء يضع طلبًا حقيقيًا وينفق رصيدًا حقيقيًا، فتعامل معه كمعاملة فعلية. استخدم أصغر كمية تسمح بها الخدمة، على رابط تملكه، ثم تحقق بالإجراء status بعدها بدل أن تفترض أن الطلب تم لأن الاستدعاء أعاد 200: فعدد من اللوحات يعيد 200 وفي متن الرد رسالة خطأ.