Skip to main content
Ba endpoint xoay quanh công việc ký của một người dùngvết phê duyệt của hồ sơ.

Base URL


Cả ba endpoint chấp nhận hai cách xác thực, chọn một:
API Key phải resolve được người dùng. Key chưa gắn tài khoản → 401 với message API key chưa gắn người dùng; tài khoản đã bị vô hiệu hoá → 401 Tài khoản dịch vụ không hoạt động. Xem Xác thực.API Key trả về công việc của chính tài khoản gắn với key. Muốn lấy danh sách theo từng người ký, dùng access token của người đó (lấy qua partner-login).
Access token đi ở header x-access-token, không phải Authorization: Bearer. Gửi đồng thời cả hai header thì X-API-Key được ưu tiên.

1. Danh sách công việc ký

Body

Không có. Đây là request GET, mọi tham số truyền qua query string.

Query

Giá trị của status

Giá trị là bản viết thường của items[].status, cộng hai giá trị gộp: Các tập con cộng lại đúng bằng tập cha: approved + rejected + expired = completed, và pending + completed = all.
Tham số không nằm trong bảng trên bị bỏ qua, không báo lỗi.

Response

Trường cấp data

Trường của items[]

Trường của items[].document

items[].status được suy ra từ đâu

Hành động được ưu tiên hơn trạng thái công việc: một bước có thể đã bị đóng bởi bước sau, nhưng lượt xử lý của bạn vẫn phải phản ánh đúng việc bạn đã làm.
Danh sách trả về mọi công việc của người dùng, kể cả hồ sơ do người dùng tạo trực tiếp trên web. Những hồ sơ đó không có mã bạn cấp nên document.documentId rỗng — hãy dùng document.documentUuid làm định danh ổn định trong trường hợp này.
Trường không có giá trị được lược khỏi JSON, không trả null. Ví dụ hồ sơ chờ ký sẽ không có actionAtcomment; bước không đặt hạn sẽ không có expireAt.

Khác biệt giữa hai loại bản ghi

Khi status bỏ trống, hai loại được trộn và sắp xếp theo thời gian giảm dần (actionAt nếu đã xử lý, assignedAt nếu đang chờ).
Một công việc có thể xuất hiện hai lần khi bạn lấy cả hai loại: bước có nhiều người ký, bạn đã ký phần mình (bản ghi APPROVED) nhưng bước vẫn đang chờ người còn lại (bản ghi PENDING). Đây là hai sự kiện khác nhau, không phải trùng lặp.

2. Chi tiết một công việc

taskCode lấy từ items[].taskCode của endpoint danh sách. Trả về toàn bộ trường của một item trong danh sách, kèm ba nhóm bổ sung: assignee, files/attachments, và history.

Trường bổ sung

usernameroleCode/roleName chỉ trả với bước ký bằng tài khoản nội bộ. Với khách mời, username hệ thống chính là CCCD/MST nên không được trả ra, tránh lộ định danh cá nhân qua trường sai ngữ nghĩa.

Lỗi


3. Lịch sử phê duyệt của hồ sơ

Toàn bộ vết phê duyệt của hồ sơ — mọi bước, mọi người ký — sắp xếp theo thời gian tăng dần, đọc từ trên xuống là đúng trình tự.

Trường của history[]

Bản ghi OVERDUE do hệ thống sinh khi bước quá hạn; actor* khi đó là người được giao bước, không phải người bấm nút.

Lỗi


Phạm vi dữ liệu

  • Danh sách công việc luôn giới hạn theo người dùng đã xác thực: công việc gán trực tiếp, gán cho vai trò họ đảm nhiệm, hoặc do người khác uỷ quyền cho họ (uỷ quyền chỉ áp cho phần chờ xử lý).
  • Khi xác thực bằng X-API-Key, kết quả còn bị giới hạn trong tổ chức của API Key. Với access token thì không — phạm vi giống hệt những gì người dùng thấy trên web/app.
  • Với lịch sử phê duyệt hồ sơ, người ký bên ngoài chỉ đọc được hồ sơ mà họ có tham gia.
  • Không có công việc nào → items là mảng rỗng, total bằng 0. Không trả 404.
total được tính theo đúng cách web/app đếm — phần chờ xử lý đếm số công việc, phần đã xử lý đếm số lượt xử lý — nên con số khớp với màn hình Xử lý công việc của người dùng.

Lỗi chung

Chi tiết: Mã lỗi.

Bước tiếp theo

API Hồ sơ

Tạo hồ sơ, tra cứu trạng thái đầy đủ và tải file

Webhook

Nhận thông báo thay vì hỏi vòng (polling)