Vor dem Verknüpfen hochladen
Laden Sie die Dateien für eine einzelne Kategorie von Nachweisen oder ergänzenden Dokumenten hoch und verknüpfen Sie anschließend die zurückgegebenen Datei-IDs mit create_proof oder create_supporting_document. Durch das Hochladen allein werden weder eine Identität noch eine Adresse, ein Nachweis oder eine abgeschlossene Rufnummernregistrierung erstellt. Beginnen Sie mit den aktuellen Anforderungen und Katalog-IDs.
Geben Sie genau einen Auswahlparameter an: proof_type_id für einen Identitäts- oder Adressnachweis oder supporting_template_id für ein ergänzendes Dokument. Senden Sie nicht beide. Verwenden Sie die vom jeweiligen MultiTEL-Katalog zurückgegebenen IDs; behandeln Sie diese als undurchsichtige Kennungen, aus deren Aufbau Sie keine Bedeutung ableiten.
Upload-Anfrage
Verwenden Sie ein freigeschaltetes MultiTEL-API-Konto und die dafür zugelassene IP-Adresse. Die Beispiele verwenden Zugangsdaten für HTTP Basic aus Umgebungsvariablen; beachten Sie die Authentifizierungskonventionen für Ihren Kontotyp. Senden Sie Anfragen über HTTPS. Prüfen Sie sowohl die HTTP-Antwort als auch das JSON-Feld status.code; Anwendungsfehler können mit HTTP 200 zurückgegeben werden. Die folgenden Beispiele sind fiktiv.
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| Feld | Bedeutung |
|---|---|
files[0] … files[4] | Eine bis fünf hochgeladene Dateien. Verwenden Sie mehrteilige Formulardaten und lassen Sie curl die zugehörige Trennzeichenfolge für Content-Type erzeugen. Diese Felder enthalten die Bytes der Dateien, keine URLs und keine Base64-Daten in JSON. |
proof_type_id | Beim Hochladen eines Nachweises erforderlich; verwenden Sie eine zurückgegebene Nachweistyp-ID. Lassen Sie supporting_template_id weg. |
supporting_template_id | Für ergänzende Dateien anstelle von proof_type_id erforderlich; verwenden Sie eine zurückgegebene Vorlagen-ID. |
description | Optionale, vom Aufrufer angegebene Beschreibung mit höchstens 100 Zeichen. Beim Hochladen ergänzender Dokumente kann der Vorlagenname verwendet werden, wenn die Beschreibung fehlt. |
Dateigrenzen
Diese Verarbeitungsroutine akzeptiert höchstens fünf Dateien mit insgesamt 20,000,000 Bytes. Dies ist eine dezimale Bytegrenze, nicht 20 MiB. Die Infrastruktur oder die MIME-Validierung kann zusätzliche Grenzen vorgeben.
Die Liste der zulässigen Dateiendungen umfasst pdf, png, jpg, jpeg, gif, tiff, bmp, doc, docx, xls, xlsx, txt, rtf und csv. Eine zulässige Dateiendung belegt nicht, dass eine Datei die ausgewählte Registrierungsanforderung erfüllt. Insbesondere ist tif nicht in dieser Liste zulässiger Dateiendungen enthalten.
Jede zurückgegebene Datei prüfen
{
"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"
}
]
}
}Bewahren Sie jeden Wert von response.ids[].id für die Verknüpfungsanfrage auf. name bezeichnet den zurückgegebenen Namen der Quelldatei. Verwenden Sie unterschiedliche Dateinamen und vergleichen Sie die zurückgegebenen Dateien mit der erwarteten Dateimenge: Code 200 kann einen nur teilweise erfolgreichen Stapel bedeuten. Verknüpfen Sie keine Dateimenge, in der erforderliche Dateien fehlen.
entity_type hat den Wert identities oder addresses für einen Nachweis und supporting_documents beim Hochladen ergänzender Dokumente. document_category hat den Wert proof oder supporting. Das allgemein benannte Feld proof_type in der Antwort enthält beim Hochladen ergänzender Dokumente auch eine Vorlagenreferenz; bewahren Sie Ihren ursprünglichen Wert von supporting_template_id für die Verknüpfung auf.
Zeitnah verknüpfen
Der Dienst legt einen Ablaufzeitpunkt etwa 20 Minuten nach dem lokalen Speichern des Uploads fest. Beim Verknüpfen wird geprüft, ob die Datei demselben Konto gehört, nicht als abgelaufen markiert ist, ihren Ablaufzeitpunkt noch nicht erreicht hat und der richtigen Entitätskategorie zugeordnet ist. expired_at enthält in dieser Antwort keinen Zeitzonenversatz; gehen Sie nicht davon aus, dass der Wert in UTC angegeben ist. Verknüpfen Sie die Dateien zeitnah, statt die Verarbeitung unmittelbar am Ablaufzeitpunkt einzuplanen.
Der Ablauf der Upload-Referenz ist keine Zusage, dass zu diesem Zeitpunkt alle gespeicherten Dokumentkopien gelöscht werden. Der Dienst verschlüsselt Dateien für die Übertragung an den Netzbetreiber und bewahrt die ursprünglichen Dateibytes für den Dokumentenablauf auf; betrachten Sie dies nicht als ausschließlich clientseitige Verschlüsselung oder als Dienst ohne Datenspeicherung. Halten Sie IDs, Dateinamen und Antworten aus öffentlichen Protokollen heraus.
Fehler und Wiederholungsversuche
Die aktuelle Verarbeitungsroutine verwendet den API-Code 404, wenn keine Dokumentdateien übermittelt werden, und Code 500 bei Fehlern in der Beschreibungsvalidierung, fehlenden oder widersprüchlichen Auswahlparametern, ungültigen Nachweis- oder Vorlagen-IDs, Überschreitung der Dateianzahl oder Gesamtgröße, Speicherproblemen oder einem fehlgeschlagenen Upload. Lesen Sie status.msg; ungültige Eingaben werden nicht durchgehend mit Code 400 gekennzeichnet.
Hier steht kein clientseitiger Idempotenzschlüssel zur Verfügung. Falls die Antwort verloren geht, prüfen Sie den Dokumentenablauf, bevor Sie einen Upload wiederholen; eine weitere Anfrage kann neue Dateireferenzen erzeugen. Diese Beispiele wurden nicht mit Identitätsdokumenten von Kunden ausgeführt.