Tạo hồ sơ đăng ký

Chỉ tạo hồ sơ một lần

Yêu cầu này tạo một hồ sơ đăng ký cục bộ cùng với các bản ghi danh tính và địa chỉ phía nhà mạng. Hãy bắt đầu với danh sách hiện hành về quốc gia đăng ký, loại số và yêu cầu. Các yêu cầu phụ thuộc vào quốc gia và loại số mà bạn dự định đăng ký.

Phản hồi tạo thành công không phải là phê duyệt pháp lý hay kích hoạt số. Hãy lưu riêng UUID tài liệu, ID danh tính và ID địa chỉ: chúng phục vụ các mục đích khác nhau. Yêu cầu này thay đổi dữ liệu tài khoản và không phải là thao tác chỉ để kiểm tra hợp lệ.

Yêu cầu tạo

Xác thực bằng tài khoản MultiTEL API đã được bật và địa chỉ IP được phép của tài khoản đó. Các ví dụ sử dụng thông tin xác thực HTTP Basic lưu trong biến môi trường. Hãy kiểm tra cả phản hồi HTTP lẫn trường JSON status.code; chỉ riêng phản hồi HTTP 200 không đủ để xác nhận thành công. Mọi giá trị ví dụ đều là hư cấu.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --header 'Content-Type: application/json' \
  --data @registration-profile.json \
  https://api.multitel.net/v3/create_document

{
  "identity_type": "Personal",
  "first_name": "Example",
  "last_name": "Person",
  "phone_number": "12025550123",
  "email": "end-user@example.com",
  "city": "Example City",
  "postal_code": "00000",
  "country": "US",
  "address": "1 Example Street",
  "nationality": "US",
  "signature": "BASE64_PNG_OF_THE_AUTHORIZED_END_USER_SIGNATURE"
}

JSON này là một hồ sơ Personal minh họa, không phải danh tính thật sẵn sàng để gửi. Hãy thay thế các chi tiết và chữ ký trong đó bằng thông tin người dùng cuối mà quy tắc đăng ký đã chọn yêu cầu. Dữ liệu đầu vào mã hóa dạng biểu mẫu (form-encoded) cũng được hỗ trợ.

Trình xử lý v3 trực tiếp này yêu cầu các trường địa chỉ và sẽ tạo một địa chỉ. Đừng cho rằng tùy chọn hoãn nhập địa chỉ của cổng thông tin có sẵn thông qua nó.

Lưu giữ cả ba mã định danh

Phần sau đây chỉ hiển thị một số trường phản hồi được chọn; phản hồi thực tế còn chứa thông tin hồ sơ đã gửi và dữ liệu chữ ký. Hãy xử lý toàn bộ phản hồi như dữ liệu riêng tư.

{
  "status": {
    "code": 200,
    "msg": "Success Create Registration Detail."
  },
  "response": {
    "uuid": "11111111111111111111111111111111",
    "identity_id": "22222222222222222222222222222222",
    "address_id": "33333333333333333333333333333333",
    "country_iso": "US",
    "email": "end-user@example.com"
  }
}

• response.uuid xác định hồ sơ cục bộ. Hãy dùng nó với get_document. Trong các phản hồi của documents và get_document, cùng mã định danh hồ sơ này được đặt tên là id.
• response.identity_id xác định danh tính dùng cho các bước gửi sau này về bằng chứng danh tính và tài liệu hỗ trợ.
• response.address_id xác định địa chỉ đã được tạo. Hãy lưu riêng nó; UUID hồ sơ cục bộ không phải là ID địa chỉ. Khả năng tương thích của việc đính kèm bằng chứng địa chỉ sau này cho các hồ sơ mới tạo vẫn đang được xem xét.

Hai điểm cuối đọc lại hồ sơ không trả về identity_id hay address_id, vì vậy hãy lưu giữ phản hồi tạo thành công ban đầu. Nếu phản hồi đó bị mất, hãy dùng chế độ xem tài liệu trên cổng thông tin hoặc liên hệ bộ phận hỗ trợ trước khi tạo hồ sơ thay thế.

Nâng cao: đính kèm bằng chứng đã tải lên trước trong lúc tạo

Bạn có thể cung cấp identity_encryptfiles và address_encryptfiles dưới dạng mảng các ID do create_encrypt_files trả về. Hãy tải lên bằng loại bằng chứng dành cho danh mục thực thể tương ứng, rồi gửi trước khi tham chiếu tệp hết hạn sau khoảng 20 phút. Trình xử lý tạo sẽ kiểm tra tài khoản, danh mục và thời hạn của từng tham chiếu được cung cấp.

Các trường này có tên khác với encrypted_file_ids của điểm cuối đính kèm sau này. Trong lúc tạo, mỗi tệp được gửi như một yêu cầu bằng chứng riêng biệt, ngay cả khi nhiều tệp dùng chung một loại bằng chứng. Đối với bằng chứng danh tính phải chứa nhiều tệp cùng nhau, hãy dùng yêu cầu create_proof sau này với một mảng duy nhất. Chỉ riêng việc tạo hồ sơ thành công không cung cấp kết quả phê duyệt của từng bằng chứng.

Nếu bằng chứng địa chỉ sau này bị từ chối đối với một địa chỉ mới tạo, đừng thay thế bằng UUID hồ sơ hay tạo lại danh tính nhiều lần. Hãy dừng lại và kiểm tra hồ sơ trên cổng thông tin hoặc với bộ phận hỗ trợ. Đường dẫn đọc lại/tra cứu bằng chứng địa chỉ vẫn là một hạn chế đang được xem xét.

Lỗi và tạo không hoàn chỉnh

Mã API 400 bao gồm lỗi kiểm tra hợp lệ trường, lỗi tạo phía nhà mạng và lỗi lưu cục bộ. Các lỗi kiểm tra hợp lệ có thể xuất hiện dưới dạng các mục khóa theo tên trường trong response. Mã 500 được dùng cho quốc gia đăng ký không khả dụng/không hợp lệ, và mã 404 cho các tham chiếu đã tải lên trước bị thiếu hoặc hết hạn. Hãy đọc cả status.msg lẫn mã lỗi.

Các thao tác trên hồ sơ cục bộ và phía nhà mạng thượng nguồn không phải là một giao dịch nguyên tử duy nhất. Một yêu cầu thất bại có thể để lại trạng thái ở phía thượng nguồn ngay cả khi không có hồ sơ cục bộ nào được liệt kê. Không có khóa idempotency phía máy khách nào được cung cấp. Sau khi hết thời gian chờ hoặc gặp lỗi không rõ ràng, hãy kiểm tra các hồ sơ hiện có và liên hệ bộ phận hỗ trợ trước khi lặp lại việc tạo; danh sách documents trống không phải là bằng chứng rằng không có gì được tạo ở phía thượng nguồn.