Ambil proses Human Token berdasarkan pengenalnya — setelah pengguna kembali dari Human Token Journey, atau untuk mengkueri ulang hasil API Only.
Endpoint
| Lingkungan | URL |
|---|---|
| Produksi | GET https://humantoken.unico.app/client/v1/process/{processId} |
Permintaan
| Header | Nilai |
|---|---|
x-unico-accesskey | <your_access_key> (lihat Autentikasi) |
| Parameter | Tipe | Wajib | Deskripsi |
|---|---|---|---|
processId | string (UUID) | ya | Pengenal proses yang dikembalikan oleh Buat Proses. |
Contoh
- cURL
- Node.js
curl -X GET https://humantoken.unico.app/client/v1/process/$PROCESS_ID \
-H "x-unico-accesskey: $UNICO_ACCESS_KEY"
import fetch from 'node-fetch';
const res = await fetch(
`https://humantoken.unico.app/client/v1/process/${processId}`,
{ headers: { 'x-unico-accesskey': process.env.UNICO_ACCESS_KEY } }
);
const result = await res.json();
// result.data.humanToken.value
Respons
Respons memiliki format yang sama dengan Buat Proses. Bentuk data bergantung pada alur yang digunakan saat proses dibuat.
Alur standar (api+humantoken, api+liveness+humantoken, humantoken):
{
"id": "6ed74799-4c2f-4023-b43f-a73cf7c847b2",
"state": "PROCESS_STATE_FINISHED",
"data": {
"humanToken": {
"value": "3f9a1c7e5b2d4086a1e3c5f7092b4d6e8a0c2e4f6183a5c7e9b1d3f5072a4c6e",
"status": "validated"
}
}
}
Alur revalidasi (api+liveness+humantoken+revalidation, humantoken+revalidation):
{
"id": "cb0472c0-6dbc-46c6-b830-2be7edc35424",
"state": "PROCESS_STATE_FINISHED",
"data": {
"humanTokenMatch": "true"
}
}
| Field | Tipe | Deskripsi |
|---|---|---|
id | string (UUID) | Pengenal proses. |
state | string | Status proses — lihat nilai state. |
data.humanToken.value | string | Hanya alur standar. Pengenal wajah yang stabil dan buram (hingga 100 karakter). Orang yang sama selalu menghasilkan nilai yang sama. |
data.humanTokenMatch | string | Hanya alur revalidasi. "true" jika selfie cocok dengan humanToken yang direferensikan, "false" jika tidak. |
| Nilai | Arti |
|---|---|
PROCESS_STATE_UNSPECIFIED | Status tidak ditetapkan. |
PROCESS_STATE_CREATED | Proses telah dibuat dan masih menerima sesi baru. data bernilai {}. |
PROCESS_STATE_FINISHED | Proses telah selesai dan tidak lagi menerima sesi baru. Untuk alur standar, data.humanToken ada jika Human Token berhasil dibuat; untuk alur revalidasi, data.humanTokenMatch menunjukkan apakah selfie cocok dengan token yang direferensikan. Jika tidak, data bernilai {}. |
PROCESS_STATE_FAILED | Proses gagal. data bernilai {}. |
PROCESS_STATE_CANCELED | Proses dibatalkan. data bernilai {}. |
PROCESS_STATE_AWAITING_FOR_DOCUMENT | Proses menunggu dokumen identitas. data bernilai {}. |
Selalu pastikan data.humanToken.value tidak kosong sebelum menggunakannya.
Kode Error
- 400 Bad Request
- 401 Unauthorized
- 404 Not Found
- 429 Too Many Requests
- 500 Internal Server Error
| Kode | Pesan | Deskripsi |
|---|---|---|
3 | process id is invalid | Ketika ID proses tidak valid. |
Access key tidak ada atau tidak valid di header x-unico-accesskey. Lihat Autentikasi.
| Kode | Pesan | Deskripsi |
|---|---|---|
5 | error getting process: rpc error: code = NotFound desc = process not found | Ketika ID proses tidak ditemukan. |
Batas rate tercapai. Ketika sistem Anda menerima error HTTP 429, Anda harus mengimplementasikan mekanisme untuk mencegah kegagalan berantai dan menghindari memperburuk pembatasan.
Praktik terbaik:
- Periode pendinginan (backoff): Segera hentikan atau kurangi permintaan berikutnya dari sistem Anda. Jangan terus-menerus mencoba ulang permintaan yang gagal dalam loop yang ketat.
- Antrean & pembatasan (Queueing & throttling): Buffer atau antrean permintaan keluar dari sisi Anda untuk mengontrol aliran lalu lintas sebelum mengirimnya kembali.
- Exponential backoff dengan jitter: Saat mencoba ulang, tingkatkan waktu tunggu secara eksponensial antar percobaan (misalnya, 1 s, 2 s, 4 s, 8 s) dan tambahkan penundaan acak kecil ("jitter") untuk mencegah efek kawanan di mana semua permintaan yang diantrean mencoba ulang pada milidetik yang sama persis.
Terus-menerus mengirim permintaan ke endpoint yang dibatasi rate tanpa menerapkan backoff dapat memperpanjang periode pembatasan dan sangat memengaruhi throughput operasional sistem Anda. Membatasi permintaan dengan benar dari sisi Anda memastikan integrasi yang lebih lancar dan lebih tangguh.
Untuk batas default, peningkatan permintaan, dan detail tambahan, lihat Batas Rate.
| Kode | Pesan | Deskripsi |
|---|---|---|
99999 | Internal failure! Try again later | Ketika terjadi kesalahan internal. |
Selanjutnya
- Kembali ke Buat Proses untuk mengirim selfie baru.
- Untuk memahami apa yang diwakili oleh
humanTokendan kapan ia tidak dihasilkan, lihat ikhtisar Human Token.