העלאת קובצי אסמכתה לרישום

העלו לפני הצירוף

העלו את הקבצים לקטגוריה אחת של אסמכתה או מסמך נלווה, ולאחר מכן צרפו את מזהי הקבצים שהוחזרו באמצעות create_proof או create_supporting_document. העלאה לבדה אינה יוצרת זהות, כתובת, אסמכתה או רישום מספר שהושלם. התחילו עם הדרישות העדכניות ומזהי הקטלוג.

ספקו פרמטר בחירה אחד בדיוק: proof_type_id לאסמכתה לזהות או לכתובת, או supporting_template_id למסמך נלווה. אל תשלחו את שניהם. השתמשו במזהים שהוחזרו מהקטלוג המתאים של MultiTEL; התייחסו אליהם כמזהים שאין להסיק משמעות מהמבנה שלהם.

בקשת העלאה

השתמשו בחשבון API פעיל של MultiTEL ובכתובת ה-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.

לא מוצע כאן מפתח אידמפוטנטיות ללקוח. אם התגובה אבדה, בדקו את תהליך הטיפול במסמכים לפני שתעלו שוב; בקשה נוספת עשויה ליצור הפניות חדשות לקבצים. דוגמאות אלה לא הורצו עם מסמכי זהות של לקוחות.