استقبل SMS عبر API أو لوحة التحكم: أي سير عمل يناسبك؟
استخدم لوحة تحكم للطلبات اليدوية العرضية. لا تفكر في واجهة برمجة تطبيقات استقبال موثقة لدى مزود إلا عندما تحتاج سير عمل معتمد إلى برنامج لطلب رقم ومتابعة طلبه وقراءة رسالة واردة.
نُشر بواسطة OTPAtlas، وهي خدمة أرقام SMS مؤقتة. يستعرض هذا الدليل وثائق API والمنتج الرسمية التي فُحصت في 23 سبتمبر 2026. وهو شرح، وليس اختبار تكامل فعلي. ولا تعلن OTPAtlas حالياً عن API عام.
ميّز أولاً بين ثلاثة واجهات برمجة تطبيقات مختلفة
واجهة برمجة تطبيقات استقبال الأرقام المؤقتة تطلب أو تستأجر رقماً ثم تسترجع SMS الوارد لذلك الطلب. تعرض لوحة التحكم اليدوية نفس نوع الطلب والرسالة لشخص في متصفح. واجهة برمجة تطبيقات الإرسال أو التحقق، مثل Twilio Verify، تبدأ التحقق بإرسال كود إلى جهاز المستخدم نفسه. تقع هذه المنتجات على جانبي الرسالة المتقابلين. قد يعيد البحث عن "SMS verification API" أي منهما، لذا تحقق من الاتجاه قبل اختيار الوثائق.
يوفّر OTPAtlas حالياً لوحة تحكم بعد تسجيل الدخول لاختيار طلبات الأرقام المؤقتة ومتابعتها. ولا يوفّر واجهة برمجة تطبيقات عامة موثّقة للمطورين الخارجيين. توضح أمثلة المزوّدين أدناه كيف تختلف واجهات برمجة التطبيقات الخارجية الموثّقة عن لوحة التحكم اليدوية؛ وهي ليست نقاط نهاية لـ OTPAtlas.
| سير العمل | من يستخدمه | ما يفعله | ليس مماثلاً لـ |
|---|---|---|---|
| لوحة الاستقبال اليدوي | شخص لديه طلب مسموح به من حين لآخر | يختار عرضًا ويقرأ الرقم المخصص وSMS المستلَم | واجهة برمجة تطبيقات عامة للمطورين |
| API لرقم الاستقبال | مطوّر يمتلك حساب مزوّد مدعومًا | يطلب الرقم ويتتبع الطلب ويسترد الرسائل الواردة SMS | واجهة API ترسل الرموز |
| واجهة برمجية لإرسال التحقق | مالك تطبيق يتحقق من مستخدميه | يرسل رمزًا إلى جهاز المستخدم ويتحقق من الاستجابة | شراء رقم لاستقبال رمز طرف ثالث |
المصادر: وثائق واجهة برمجة تطبيقات الاستقبال لدى 5SIM · دليل طلب/فحص واجهة برمجة تطبيقات SMSPool · واجهة برمجة تطبيقات إرسال Twilio Verify
متى تكون لوحة التحكم الأداة الأفضل
لرمز عرضي واحد، تُبقي لوحة التحكم القرار البشري ظاهراً: أكّد قواعد خدمة الاستقبال، وقارن البلدان المسموح بها، واقرأ السعر والمخزون المباشرين، ومَوّل حساباً إذا لزم، وراجع الطلب الدقيق قبل التأكيد. على OTPAtlas، تعرض علامة تبويب SMS بعد ذلك الرقم المعيّن وصلاحية الطلب الدقيقة بعد التعيين والحالة وأي رسالة مسجّلة؛ ويُظهر السجل ونشاط الرصيد النتيجة النهائية. لا حاجة إلى تكامل برمجي لطرح تلك الأسئلة.
لا تجعل واجهة API دولة مستبعدة مؤهلة، أو تنشئ مخزونًا، أو تمدد رقمًا قصيرًا، أو تضمن قبول منصة طرف ثالث له. إذا كان الجزء الصعب هو اختيار الرقم الصحيح أو فهم رصيد عدم وجود رسالة، فقد تكرر الأتمتة خيارًا سيئًا بشكل أسرع فقط. استخدم لوحة التحكم حتى يُفهم القرار نفسه ويتكرر بما يكفي لتبرير الكود.
ما توثقه واجهة برمجة تطبيقات استقبال مدعومة فعليًا
تفصل وثائق 5SIM الرسمية بين المنتجات والأسعار، وشراء رقم تنشيط، وفحص طلب لمدة SMS، والإنهاء والإلغاء، والحالات. لا تزال شروطه العامة تحكم المشترين الذين يستخدمون API، بما في ذلك قيد الأهلية للولايات المتحدة/روسيا. توثق دليل SMSPool معرّف الطلب، وفحوصات الحالة لرمز معلّق أو مكتمل، والإلغاء واستجابات الأخطاء مثل نفاد المخزون أو الرصيد غير الكافي. توثق OnlineSIM نقاط نهاية التنشيط والإيجار. يحيل HeroSMS المستخدمين إلى وثائق API الخاصة به وينشر حدود الطلبات في قواعده، بينما لم يتم اختبار توافقه المعلن مع SMS-Activate هنا.
هذه عقود خاصة بكل مزوّد. لا تلصق أسماء معاملات مزوّد أو أرقام حالات أو منطق استرداد في تكامل آخر. استخدم الوثائق الحالية للمزوّد والمنتج الذي اخترته فعلاً، بما في ذلك ما إذا كانت الواجهة البرمجية تدعم خيارات الدولة والمشغل والإيجار نفسها التي رأيتها في لوحة تحكمه.
المصادر: 5وثائق واجهة برمجة تطبيقات SIM · 5شروط SIM · دليل طلب/فحص واجهة برمجة تطبيقات SMSPool · منتجات واجهة برمجة تطبيقات OnlineSIM · واجهة برمجة تطبيقات HeroSMS وقواعدها
صمّم دورة حياة الطلب قبل أتمتته
التدفق المفاهيمي الآمن هو: اقرأ المنتجات والسعر الحالي؛ تأكد من أن الحساب مؤهل وممول؛ أرسل طلباً واحداً؛ خزّن معرف الطلب المُعاد؛ افحص نفس الطلب بحثاً عن حالات الانتظار أو استلام SMS أو الإلغاء أو انتهاء الصلاحية؛ وقم بتسوية أي حركة رصيد. إذا قدم المزود إلغاءً، فطبق توقيته الفعلي وقاعدة عدم الرسائل. يخبر دليل SMSPool المتكاملين صراحةً بالاحتفاظ بمعرف الطلب واستقصاء نقطة نهاية الفحص لأنه لا يدفع إشعارات لذلك التدفق.
انتهاء مهلة الطلب بعد إرسال الطلب غامض: قد يكون المزود قد أنشأ الطلب حتى لو لم يرَ عميلك الاستجابة. لا ترسل طلب شراء مدفوع ثانٍ بشكل أعمى. افحص أولاً سجل طلبات المزود أو مرافق الحالة وقم بالتسوية عبر سجل طلب محلي. لم نجد مفتاح idempotency موثقاً مشتركاً بين هؤلاء المزودين؛ اسأل عما إذا كانت نقطة النهاية المختارة تدعم واحداً. هذا احتياط هندسي، وليس وعداً بسلوك المزودين.
المصادر: واجهة برمجة تطبيقات الطلب والسجل لدى 5SIM · معرّف طلب SMSPool وحالته والاستعلام الدوري
التعامل مع الأخطاء وحدود المعدل والأسرار كقرارات منتج
تعني «غير متوفر» أن المنتج المحدد غير متاح؛ ويعني «رصيد غير كافٍ» أن التمويل مطلوب. وليس أي منهما إشارة إلى شراء دولة مختلفة تلقائياً إذا كانت المنصة المستقبِلة تمنع ذلك. وتوثّق SMSPool هذين النوعين من الاستجابة. وتنشر 5SIM حدود الطلبات واستجابات 429 أو 503 للحدود المختلفة؛ وتنشر HeroSMS حدود طلبات API في قواعدها الحالية. اقرأ الحدود الحالية للمزوّد واستخدم إعادة محاولة أو تراجعاً مضبوطاً لفحوص الحالة، مع تجنّب إعادة المحاولة غير المضبوطة لطلب الشراء.
احتفظ بمفاتيح API على خادم موثوق بدلًا من صفحة متصفح عامة، وحدّ من الوصول إلى السجلات التي تحتوي على أرقام هواتف أو نص رسائل، واحتفظ فقط بما يحتاجه سير العمل. تتبّع معرّف الطلب والنتيجة النهائية حتى يتمكن سؤال الدعم من تحديد حدث معين. لا يحتاج مستخدم لوحة التحكم إلى بناء هذه الضوابط؛ أما المطوّر الذي يستخدم API فيحتاج إليها. لا يمنح أي من الواجهتين إذنًا بتجاوز قواعد منصة الاستقبال.
المصادر: أخطاء واجهة برمجة تطبيقات SMSPool · 5حدود واجهة برمجة تطبيقات SIM · قواعد واجهة برمجة تطبيقات HeroSMS
خياران كاملان
الحالة أ: يحتاج شخص إلى رمز واحد مسموح به هذا الأسبوع. يمكنه استخدام لوحة تحكم OTPAtlas للتحقق من عرض خدمة-دولة مباشر، والتمويل فقط بعد فهم الحد الأدنى للتعبئة، وتأكيد الطلب وقراءة حالة SMS. إنشاء تكامل API سيضيف عملًا يتعلق ببيانات الاعتماد ومعالجة الأخطاء دون تغيير أهلية الرقم أو مدته.
الحالة ب: يختبر فريق ما تدفق التسجيل المعتمد الخاص به عبر دول مسموح بها بشكل متكرر. قد يقلل مزود لديه واجهة برمجة تطبيقات استقبال رسمية من النسخ اليدوي إذا كان الفريق قادرًا على تنفيذ دورة حياة الطلب، وحماية بيانات الاعتماد، وتسوية المشتريات الغامضة، واحترام حدود المعدل. إذا كان الفريق بحاجة بدلاً من ذلك إلى إرسال رموز التحقق إلى مستخدميه، فعليه فحص منتج إرسال مثل Twilio Verify، وليس واجهة برمجة تطبيقات استقبال الأرقام المؤقتة.
المصادر: واجهة برمجة تطبيقات الاستقبال لدى 5SIM · واجهة برمجة تطبيقات إرسال Twilio Verify
الأسئلة الشائعة
هل يقدم OTPAtlas واجهة برمجة تطبيقات عامة للاستقبال؟
لا توجد واجهة برمجة تطبيقات عامة للمطورين موثقة لـ OTPAtlas في هذا الإصدار. مسار المستخدم المدعوم هو لوحة التحكم بعد تسجيل الدخول؛ أمثلة واجهة برمجة المزود الخارجي في هذا الدليل هي خدمات منفصلة.
هل يمكن لواجهة برمجة التطبيقات (API) تحسين قبول SMS؟
تقوم واجهة API بأتمتة عمليات الطلب والرسائل المدعومة. لا تغير قواعد المنصة المستقبلة، أو نوع الرقم، أو المخزون المباشر.
هل Twilio Verify واجهة برمجية لشراء أرقام لتلقي الرموز؟
لا. يبدأ Twilio Verify عمليات التحقق ويفحصها لمستخدمي تطبيق معيّن بإرسال رموز إلى أجهزتهم. وهذا اتجاه مختلف عن واجهة برمجة استقبال الأرقام المؤقتة.
ماذا لو انتهت مهلة طلب الشراء؟
اعتبر النتيجة غير مؤكدة. راجع سجل الطلبات أو حالتها وقم بالتسوية قبل إرسال طلب شراء آخر؛ وإلا فقد تنشئ طلبًا مدفوعًا ثانيًا.
هل ينبغي أن أستعلم كل ثانية عن رمز؟
اتبع الحدود الموثقة وإرشادات الاستعلام الدوري الخاصة بالمزوّد المختار. يصف SMSPool الاستعلام الدوري المجدول لنقطة التحقق الخاصة به؛ وينشر 5SIM وHeroSMS حدود الطلبات. زيادة الطلبات لا تجعل الرسالة تصل أسرع.
قبل أن تقرر
- تأكد مما إذا كانت المهمة استقبال رمز طرف ثالث أو إرسال رمزك الخاص.
- استخدم لوحة التحكم للطلبات اليدوية العرضية؛ واطلب توثيق واجهة برمجة التطبيقات الرسمية للأتمتة.
- صمّم نموذج معرّف الطلب والحالات والأخطاء ومخاطر الشراء المكرر وحدود المعدل قبل التكامل.
- للأتمتة، اختر مزوّداً لديه وثائق حالية لواجهة استقبال API وتحقق من قواعد منصة الاستقبال.