فیکس بھیجیں

بھیجنے سے پہلے

بھیجنے کے لیے ایسا نمبر استعمال کریں جسے ظاہر کرنے کی آپ کو اجازت ہو، اور ایسے وصول کنندہ کو فیکس بھیجیں جو اس کا منتظر ہو۔ یہ درخواست حقیقی ترسیل شروع کرتی ہے جس پر چارج لگ سکتا ہے۔ صفحات کی شناخت میں زیادہ سے زیادہ قابلِ پیش گوئی نتائج کے لیے پہلے سے تیار کردہ PDF یا TIFF دستاویز استعمال کریں۔ قطار میں شامل ہونے کا جواب درخواست کی قبولیت کی تصدیق کرتا ہے، فیکس پہنچنے کی نہیں۔

MultiTEL کا فعال API اکاؤنٹ استعمال کریں۔ پاس ورڈ والے اکاؤنٹ کے لیے HTTP Basic کی اسناد بھیجیں، یا ٹوکن والے اکاؤنٹ کے لیے Bearer ٹوکن بھیجیں۔ اکاؤنٹ کی اجازتیں اور آئی پی پتوں کی پابندیاں بدستور لاگو رہتی ہیں۔ پس منظر میں کام کرنے والے اندرونی جزو کی اسناد استعمال نہ کریں۔

دستاویز اپ لوڈ کریں

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --form-string from_number=+12125550123 \
  --form-string to_number=+12125550124 \
  --form fax_file=@./document.pdf \
  https://api.multitel.net/v3/send_fax

JSON بھی قبول کیا جاتا ہے، جس کے لیے یہ استعمال کریں: Content-Type: application/json، نمبروں کے وہی خانے اور اختیاری webhook_url، نیز file_name اور file_b64۔ file_b64 میں دستاویز کے بائٹس مکمل طور پر درست Base64 رمز بندی میں ہوتے ہیں، جن سے پہلے data: کا سابقہ نہیں ہوتا۔ کثیر حصوں والی درخواست میں درست fax_file کو ترجیح دی جاتی ہے۔ یہ ویب پتے سے فائل حاصل کرنے کا API نہیں ہے۔

دستاویز اور درخواست جمع کرانے کی حدود

ایپلی کیشن رمز بندی کھولنے کے بعد دستاویز کے زیادہ سے زیادہ 15,728,640 بائٹس (15 MiB) قبول کرتی ہے، جن کی فائل توسیع pdf، tif، tiff، jpg، jpeg، png، doc، docx یا txt ہو۔ کسی فائل توسیع کی اجازت ہونے سے یہ ضمانت نہیں ملتی کہ سروس صفحات گن سکے گی یا ان کی وضع تبدیل کر سکے گی۔ بنیادی ڈھانچے میں درخواست کی حدود اس سے کم ہو سکتی ہیں، اور Base64 سے درخواست کا حجم بڑھ جاتا ہے۔

موجودہ ایپلی کیشن ہر اکاؤنٹ کے لیے ایک ہی منزل پر قطار میں موجود یا بھیجے جانے والے ایک کام کی اجازت دیتی ہے، گزشتہ ایک گھنٹے میں اسی منزل کے لیے زیادہ سے زیادہ پانچ درخواستیں، اور گزشتہ ایک گھنٹے میں مجموعی طور پر زیادہ سے زیادہ 50 درخواستیں جمع کرانے کی اجازت دیتی ہے۔ شرح کی حد سے متعلق جواب میں API کوڈ 429 استعمال ہوتا ہے۔ دوبارہ کوشش کرنے سے پہلے انتظار کریں؛ حدود کو نظرانداز کرنے کی کوشش نہ کریں۔

کام کا شناختی نمبر محفوظ رکھیں

HTTP کا نتیجہ اور JSON میں status.code دونوں پڑھیں۔ JSON میں ناکامی کے جوابات HTTP 200 کے ساتھ بھی آ سکتے ہیں۔ کامیاب JSON جواب میں status اور response ہوتے ہیں؛ مثالوں میں فرضی معلومات استعمال کی گئی ہیں۔

{
  "status": {
    "code": 200,
    "msg": "Fax queued"
  },
  "response": {
    "job_id": "0123456789abcdef0123456789abcdef"
  }
}

وقفے وقفے سے حالت معلوم کرنے کے لیے رجوع کریں: fax_status، اور اس کے لیے response.job_id استعمال کریں۔ اگر بھیجنے کا جواب ضائع ہو جائے تو دوبارہ بھیجنے سے پہلے پورٹل میں بھیجے جانے والے فیکسوں کا خانہ دیکھیں: بار بار کی گئی درخواستیں الگ الگ ترسیلات بنا سکتی ہیں۔ درخواست سنبھالنے والا یہ جزو کلائنٹ کو ایسا کوئی پیرامیٹر فراہم نہیں کرتا جو یقینی بنائے کہ درخواست دہرانے سے اضافی کارروائی نہیں ہوگی۔

خرابیاں اور دستیاب رقم کی جانچ

API کوڈز میں خانے غائب ہونے، واپسی اطلاع کا ویب پتہ غلط ہونے، دستاویز مسترد ہونے یا صفحات کی شناخت میں ناکامی کے لیے 400؛ توثیق موجود نہ ہونے کے لیے 401؛ فیکس کی تخمینی لاگت اور قطار میں موجود یا بھیجے جانے والے کاموں کے لاگت کے تخمینوں کا مجموعہ اکاؤنٹ میں دستیاب رقم سے بڑھ جانے پر 402؛ شرح کی حدود کے لیے 429؛ اور ترسیل سے پہلے تیاری کے مرحلے میں ناکامی کے لیے 500 شامل ہیں۔ مخصوص وجہ جاننے کے لیے status.msg پڑھیں۔

قطار ترسیل سے پہلے تخمینی لاگت درج کرتی ہے۔ قبولیت، دستیاب رقم کی جانچ یا اس تخمینے کو چارج وصول ہو جانے کی تصدیق نہ سمجھیں۔ حتمی بلنگ اور واپسی اطلاع کی تفصیلات کی تصدیق ابھی باقی ہے۔