Przesyłanie plików potwierdzających dane do rejestracji

Prześlij przed dołączeniem

Prześlij pliki dla jednej kategorii potwierdzenia lub dokumentu uzupełniającego, a następnie dołącz zwrócone identyfikatory plików za pomocą create_proof lub create_supporting_document. Samo przesłanie nie tworzy tożsamości, adresu ani potwierdzenia i nie kończy rejestracji numeru. Zacznij od zapoznania się z aktualnymi wymaganiami i identyfikatorami z katalogów.

Podaj dokładnie jeden parametr wyboru: proof_type_id dla potwierdzenia tożsamości lub adresu albo supporting_template_id dla dokumentu uzupełniającego. Nie wysyłaj obu. Używaj identyfikatorów zwróconych przez odpowiedni katalog MultiTEL; traktuj je jako nieprzezroczyste identyfikatory i nie wywodź znaczenia z ich struktury.

Żądanie przesłania plików

Użyj aktywnego konta API MultiTEL i dozwolonego dla niego adresu IP. Przykłady korzystają z danych uwierzytelniających HTTP Basic pobieranych ze zmiennych środowiskowych; przestrzegaj zasad uwierzytelniania właściwych dla swojego typu konta. Wysyłaj żądania przez HTTPS. Sprawdzaj zarówno odpowiedź HTTP, jak i pole JSON status.code; błędy aplikacji mogą być zwracane z HTTP 200. Poniższe przykłady są fikcyjne.

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

Pola żądania
Pole	Znaczenie
`files[0] … files[4]`	Od jednego do pięciu przesyłanych plików. Użyj wieloczęściowych danych formularza i pozwól curl wygenerować separator części dla Content-Type. Te pola zawierają bajty plików, a nie adresy URL ani dane Base64 w JSON.
`proof_type_id`	Wymagane przy przesyłaniu potwierdzenia; użyj zwróconego identyfikatora typu potwierdzenia. Pomiń supporting_template_id.
`supporting_template_id`	Wymagane zamiast proof_type_id dla plików uzupełniających; użyj zwróconego identyfikatora szablonu.
`description`	Opcjonalny opis podany przez wywołującego, o długości najwyżej 100 znaków. Przy przesyłaniu dokumentów uzupełniających można użyć nazwy szablonu, jeśli opis zostanie pominięty.

Limity plików

Ta procedura obsługi przyjmuje najwyżej pięć plików o łącznym rozmiarze 20,000,000 bajtów. Jest to dziesiętny limit bajtów, a nie 20 MiB. Infrastruktura lub walidacja MIME mogą nakładać dodatkowe ograniczenia.

Lista dozwolonych rozszerzeń obejmuje pdf, png, jpg, jpeg, gif, tiff, bmp, doc, docx, xls, xlsx, txt, rtf i csv. Dozwolone rozszerzenie nie oznacza, że plik spełnia wybrane wymaganie rejestracyjne. W szczególności tif nie znajduje się na tej liście dozwolonych rozszerzeń.

Sprawdź każdy zwrócony plik

{
  "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"
      }
    ]
  }
}

Zachowaj każdą wartość response.ids[].id na potrzeby żądania dołączenia. name wskazuje zwróconą nazwę pliku źródłowego. Używaj różnych nazw plików i porównaj zwrócone pliki z oczekiwanym zestawem: kod 200 może oznaczać, że operacja zbiorcza powiodła się tylko częściowo. Nie dołączaj zestawu, w którym brakuje wymaganych plików.

entity_type ma wartość identities lub addresses dla potwierdzenia, a supporting_documents przy przesyłaniu dokumentów uzupełniających. document_category ma wartość proof lub supporting. Ogólnie nazwane pole proof_type w odpowiedzi zawiera również odwołanie do szablonu przy przesyłaniu dokumentów uzupełniających; zachowaj pierwotną wartość supporting_template_id na potrzeby dołączenia.

Dołącz niezwłocznie

Usługa ustawia termin wygaśnięcia na około 20 minut po lokalnym zapisaniu przesłanych danych. Podczas dołączania sprawdzane jest, czy plik należy do tego samego konta, nie jest oznaczony jako wygasły, jego termin ważności jeszcze nie minął i ma właściwą kategorię encji. expired_at nie zawiera w tej odpowiedzi przesunięcia strefy czasowej; nie zakładaj, że jest to czas UTC. Dołącz pliki niezwłocznie, zamiast planować operację na moment upływu ważności.

Wygaśnięcie odwołania do przesłanego pliku nie jest obietnicą usunięcia w tym momencie wszystkich przechowywanych kopii dokumentu. Usługa szyfruje pliki na potrzeby przesłania do operatora i zachowuje źródłowe bajty na potrzeby procesu obsługi dokumentów; nie traktuj jej jako szyfrowania wyłącznie po stronie klienta ani jako usługi bez przechowywania danych. Nie umieszczaj identyfikatorów, nazw plików ani odpowiedzi w publicznych dziennikach.

Błędy i ponawianie żądań

Obecna procedura obsługi używa kodu API 404, gdy nie dostarczono plików dokumentów, oraz kodu 500 w przypadku błędów walidacji opisu, brakujących lub sprzecznych parametrów wyboru, nieprawidłowych identyfikatorów potwierdzenia lub szablonu, przekroczenia limitu liczby plików lub ich łącznego rozmiaru, problemów z zapisem albo nieudanego przesłania. Odczytaj status.msg; nieprawidłowe dane wejściowe nie zawsze są oznaczane kodem 400.

Nie udostępniono tu klucza idempotencji dla klienta. Jeśli odpowiedź zaginie, sprawdź proces obsługi dokumentów przed ponownym przesłaniem; kolejne żądanie może utworzyć nowe odwołania do plików. Tych przykładów nie wykonano z użyciem dokumentów tożsamości klientów.