رجسٹریشن کے ثبوت کی فائلیں اپ لوڈ کریں

منسلک کرنے سے پہلے اپ لوڈ کریں

ثبوت یا معاون دستاویز کی ایک قسم کے لیے فائلیں اپ لوڈ کریں، پھر واپس ملنے والے فائل شناخت کنندگان منسلک کرنے کے لیے استعمال کریں: create_proof یا create_supporting_document۔ صرف اپ لوڈ کرنے سے شناخت، پتہ، ثبوت یا نمبر کی مکمل رجسٹریشن نہیں بنتی۔ آغاز کے لیے موجودہ تقاضے اور کیٹلاگ کے شناخت کنندگان استعمال کریں۔

انتخاب کے لیے صرف ایک پیرامیٹر دیں: proof_type_id شناخت یا پتے کے ثبوت کے لیے، یا supporting_template_id معاون دستاویز کے لیے۔ دونوں نہ بھیجیں۔ متعلقہ MultiTEL کیٹلاگ سے واپس ملنے والے شناخت کنندگان استعمال کریں؛ ان کی ساخت سے کوئی معنی اخذ نہ کریں۔

اپ لوڈ کی درخواست

فعال MultiTEL API اکاؤنٹ اور اس کا مجاز IP پتہ استعمال کریں۔ مثالوں میں ماحول کے متغیرات سے HTTP Basic کی اسناد استعمال کی گئی ہیں؛ اپنے اکاؤنٹ کی قسم کے توثیقی اصولوں پر عمل کریں۔ درخواستیں HTTPS کے ذریعے بھیجیں۔ HTTP جواب کے ساتھ JSON کا یہ فیلڈ بھی جانچیں: status.code؛ ایپلیکیشن کی خرابیاں HTTP 200 کے ساتھ بھی آ سکتی ہیں۔ ذیل کی مثالیں فرضی ہیں۔

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --form-string "proof_type_id=$PROOF_TYPE_ID" \
  --form-string 'description=Identity proof' \
  --form 'files[0]=@./identity-proof.pdf' \
  https://api.multitel.net/v3/create_encrypt_files

فائلوں کی حدود

درخواست سنبھالنے والا یہ جزو زیادہ سے زیادہ پانچ فائلیں اور مجموعی طور پر 20,000,000 بائٹس قبول کرتا ہے۔ یہ اعشاری بائٹ حد ہے، 20 MiB نہیں۔ بنیادی نظام یا MIME کی توثیق مزید حدود عائد کر سکتی ہے۔

اجازت یافتہ فائل ایکسٹینشنز کی فہرست یہ ہے: pdf، png، jpg، jpeg، gif، tiff، bmp، doc، docx، xls، xlsx، txt، rtf اور csv۔ اجازت یافتہ ایکسٹینشن ہونے سے یہ ثابت نہیں ہوتا کہ فائل رجسٹریشن کے منتخب تقاضے پر پوری اترتی ہے۔ خاص طور پر، tif اجازت یافتہ ایکسٹینشنز کی اس فہرست میں شامل نہیں ہے۔

واپس ملنے والی ہر فائل جانچیں

{
  "status": {
    "code": 200,
    "msg": "Encrypt file has been created successfully"
  },
  "response": {
    "entity_type": "identities",
    "document_category": "proof",
    "proof_type": "11111111111111111111111111111111",
    "ids": [
      {
        "id": "22222222222222222222222222222222",
        "name": "identity-proof.pdf",
        "expired_at": "2026-10-23 16:20:00"
      }
    ]
  }
}

ہر response.ids[].id کو منسلک کرنے کی درخواست کے لیے محفوظ رکھیں۔ name واپس ملنے والی اصل فائل کا نام بتاتا ہے۔ فائلوں کے الگ الگ نام رکھیں اور واپس ملنے والی فائلوں کا متوقع مجموعے سے موازنہ کریں: کوڈ 200 جزوی طور پر کامیاب بیچ کی نمائندگی کر سکتا ہے۔ ایسا مجموعہ منسلک نہ کریں جس میں لازمی فائلیں موجود نہ ہوں۔

entity_type کی قدر ان میں سے ایک ہوتی ہے: identities یا addresses ثبوت کے لیے، جبکہ supporting_documents معاون فائلوں کے اپ لوڈ کے لیے ہوتی ہے۔ document_category کی قدر ان میں سے ایک ہوتی ہے: proof یا supporting۔ عمومی نام رکھنے والا proof_type جوابی فیلڈ معاون فائلوں کے اپ لوڈ کے لیے سانچے کا حوالہ بھی رکھتا ہے؛ منسلک کرنے کے لیے اپنا اصل supporting_template_id محفوظ رکھیں۔

جلد منسلک کریں

سروس اپ لوڈ کو مقامی طور پر محفوظ کرنے کے تقریباً 20 منٹ بعد میعاد ختم ہونے کا وقت مقرر کرتی ہے۔ منسلک کرتے وقت جانچا جاتا ہے کہ فائل اسی اکاؤنٹ کی ہے، اسے زائد المیعاد نشان زد نہیں کیا گیا، اس کی میعاد ابھی ختم نہیں ہوئی، اور اس کی متعلقہ اکائی کی قسم درست ہے۔ expired_at میں اس جواب کے اندر ٹائم زون کا فرق درج نہیں ہے؛ اسے UTC فرض نہ کریں۔ کام کو میعاد ختم ہونے کے قریب مقرر کرنے کے بجائے جلد منسلک کریں۔

اپ لوڈ کے حوالے کی میعاد ختم ہونے کا یہ مطلب نہیں کہ اسی وقت دستاویز کی تمام محفوظ نقول حذف کرنے کا وعدہ کیا گیا ہے۔ سروس ٹیلی کام آپریٹر کو اپ لوڈ کرنے کے لیے فائلوں کو خفیہ کرتی ہے اور دستاویزی طریقۂ کار کے لیے اصل بائٹس محفوظ رکھتی ہے؛ اسے صرف کلائنٹ کی طرف ہونے والی خفیہ کاری یا ڈیٹا محفوظ نہ رکھنے والی سروس نہ سمجھیں۔ شناخت کنندگان، فائلوں کے نام اور جوابات عوامی لاگز میں شامل نہ کریں۔

خرابیاں اور دوبارہ کوششیں

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

یہاں کلائنٹ کے لیے یکساں درخواست دہرانے پر اضافی اثرات روکنے والی کوئی کلید فراہم نہیں کی گئی۔ اگر جواب ضائع ہو جائے تو دوبارہ اپ لوڈ کرنے سے پہلے دستاویزی طریقۂ کار کی حالت جانچیں؛ ایک اور درخواست فائلوں کے نئے حوالے بنا سکتی ہے۔ یہ مثالیں صارفین کی شناختی دستاویزات پر نہیں چلائی گئی ہیں۔