SMS تصدیق API

1. GET /api/v2/tn101/get-services — کیٹلاگ، اس شناخت کے ساتھ جس سے آپ آرڈر کریں گے اور اس کی موجودہ قیمت کے ساتھ۔
2. POST /api/v2/tn101/request-number — ایک نمبر آرڈر کریں۔ service_key لیتا ہے، ساتھ میں اختیاری state اور ایریا کوڈز۔ جواب میں آرڈر id، نمبر اور میعاد ختم ہونے کا وقت آتا ہے۔
3. GET /api/v2/tn101/get-number-details — order_id کے ساتھ اسے poll کریں۔ کوڈ آنے تک pin خالی (null) رہتا ہے اور آنے کے بعد کوڈ اسی میں ہوتا ہے۔ یہ API کی سب سے سستی ریڈ ہے اور اسی کو لوپ میں کال کرنے کے لیے بنایا گیا ہے۔
4. POST /api/v2/tn101/reject-number — جس نمبر پر کچھ نہ آیا ہو اسے ریلیز کریں۔ رقم بھی اسی سے واپس آتی ہے۔

اس راستے پر آپ کو کچھ بھی خود بخود نہیں بھیجا جاتا، اس لیے تیسرا قدم poll ہے۔ اگر آپ پوچھنے کے بجائے اطلاع پانا چاہتے ہیں تو اکاؤنٹ آرڈر کے واقعات پر webhooks بھی بھیجتا ہے، جو پینل میں سیٹ کیے جاتے ہیں۔

ہر درخواست کے ساتھ Authorization: Bearer <token> جاتا ہے۔ ٹوکن پینل میں API access کے تحت بنائے جاتے ہیں اور وہیں کسی بھی وقت بدلے جا سکتے ہیں — بدلتے ہی پرانا ٹوکن فوراً ناکارہ ہو جاتا ہے، اس لیے پہلے اپنی کنفیگریشن میں نیا ٹوکن ڈال لیں۔

بغیر درست ٹوکن کی درخواست کو 401 ملتا ہے۔ معطل اکاؤنٹ، یا جس کا API access بند ہو، اسے 403 ملتا ہے۔ جب پوری سائٹ پر API بند ہو تو ہر اینڈ پوائنٹ دکھاوا کرنے کے بجائے 503 دیتا ہے۔

ہر اینڈ پوائنٹ انہی تین خانوں کے ساتھ جواب دیتا ہے:

data میں اصل مواد ہوتا ہے، success وہ boolean ہے جس پر فیصلہ کرنا ہے، اور summery انسان کے پڑھنے کے قابل پیغام ہے۔ یہ ہجے اس صفحے کی غلطی نہیں — API ہمیشہ سے یہی خانہ بھیجتی آئی ہے، اس پر لکھی ہر انٹیگریشن میں یہی ہے، اور ایک حرف درست کرنے کے لیے اس کا نام بدلنا ان سب کو توڑ دے گا۔ summery ہی پڑھیں۔

ویلیڈیشن کی ناکامی پر 422 آتا ہے اور data میں خانوں کے نام اور ان کے ایرر پیغامات کا object ہوتا ہے، تاکہ کال کرنے والا بتا سکے کہ کون سا argument غلط تھا، نہ کہ صرف یہ کہ کچھ غلط تھا۔

API کسی سائن اپ یا پاس ورڈ ری سیٹ فلو کو mock کے بجائے اصلی کیریئر راستے پر آزمانے کا عملی طریقہ ہے — نمبر آرڈر کریں، اسی سے اپنا فارم چلائیں، کوڈ کے لیے poll کریں، اور جانچیں کہ آپ کی ایپلیکیشن آگے کیا کرتی ہے۔ یہ stub سے سست ٹیسٹ ہے مگر وہ چیزیں پکڑ لیتا ہے جو stub نہیں پکڑ سکتا: نمبر کی normalisation، لائن کی قسم کی فلٹرنگ، اور ڈیلیوری کی وہ تاخیر جو آپ کے صارفین کو واقعی پیش آئے گی۔

API پر فی سیکنڈ درخواستوں کی کوئی حد نہیں، مگر آرڈر کرنے پر دو کوٹے ہیں، اور یہ وہی ہیں جو پینل لاگو کرتا ہے:

• کھلے آرڈرز۔ ایک اکاؤنٹ ایک وقت میں صرف محدود تعداد میں ریزرو نمبر رکھ سکتا ہے۔ ایک ساتھ بہت سے کھولنے کے بجائے poll اور ریلیز کریں۔
• روزانہ منسوخ اور ایکسپائر ہونے والے آرڈرز۔ روزانہ کی حد پار کریں تو آرڈر کرنا کچھ دیر کے لیے رک جاتا ہے، اور بار بار ہونے پر یہ وقفہ بڑھتا جاتا ہے۔ ہر ریزرویشن پر اصل سپلائی خرچ ہوتی ہے چاہے کوڈ آئے یا نہ آئے، اور کوٹا اسی کی حفاظت کرتا ہے۔

دونوں کی مزید تفصیل عارضی نمبر میں ہے، جہاں بتایا گیا ہے کہ آرڈر کیسے چلتا ہے۔