プロセスの取得GET
Human Token プロセスを識別子で取得します。ユーザーが Human Token Journey から戻った後や、API Only の結果を再照会する際に使用します。
エンドポイント
| 環境 | URL |
|---|---|
| 本番 | GET https://humantoken.unico.app/client/v1/process/{processId} |
リクエスト
ヘッダー
| ヘッダー | 値 |
|---|---|
x-unico-accesskey | <your_access_key>(認証を参照) |
パスパラメータ
| パラメータ | 型 | 必須 | 説明 |
|---|---|---|---|
processId | string (UUID) | はい | プロセスの作成で返されたプロセス識別子。 |
例
- 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
レスポンス
200 OK
レスポンスの形式はプロセスの作成と同じです。data の構造は、プロセス作成時に使用されたフローによって異なります。
標準フロー(api+humantoken、api+liveness+humantoken、humantoken):
{
"id": "6ed74799-4c2f-4023-b43f-a73cf7c847b2",
"state": "PROCESS_STATE_FINISHED",
"data": {
"humanToken": {
"value": "3f9a1c7e5b2d4086a1e3c5f7092b4d6e8a0c2e4f6183a5c7e9b1d3f5072a4c6e",
"status": "validated"
}
}
}
再検証フロー(api+liveness+humantoken+revalidation、humantoken+revalidation):
{
"id": "cb0472c0-6dbc-46c6-b830-2be7edc35424",
"state": "PROCESS_STATE_FINISHED",
"data": {
"humanTokenMatch": "true"
}
}
| フィールド | 型 | 説明 |
|---|---|---|
id | string (UUID) | プロセス識別子。 |
state | string | プロセスの状態。state の値を参照してください。 |
data.humanToken.value | string | 標準フローのみ。顔の安定した不透明な識別子(最大100文字 )。同じ人物は常に同じ値に解決されます。 |
data.humanTokenMatch | string | 再検証フローのみ。セルフィーが参照された humanToken と一致する場合は "true"、一致しない場合は "false"。 |
state の値
| 値 | 意味 |
|---|---|
PROCESS_STATE_UNSPECIFIED | 状態が設定されていません。 |
PROCESS_STATE_CREATED | プロセスは作成済みで、新しいセッションをまだ受け付けます。data は {} です。 |
PROCESS_STATE_FINISHED | プロセスは完了し、新しいセッションを受け付けません。標準フローでは、Human Token が生成された場合に data.humanToken が含まれます。再検証フローでは、data.humanTokenMatch がセルフィーが参照トークンと一致したかどうかを示します。それ以外の場合 data は {} です。 |
PROCESS_STATE_FAILED | プロセスは失敗しました。data は {} です。 |
PROCESS_STATE_CANCELED | プロセスはキャンセルされました。data は {} です。 |
PROCESS_STATE_AWAITING_FOR_DOCUMENT | プロセスは本人確認書類を待っています。data は {} です。 |
警告
data.humanToken.value を使用する前に、必ず空でないことを確認してください。
エラーコード
- 400 Bad Request
- 401 Unauthorized
- 404 Not Found
- 429 Too Many Requests
- 500 Internal Server Error
| コード | メッセージ | 説明 |
|---|---|---|
3 | process id is invalid | プロセス ID が無効な場合。 |
x-unico-accesskey ヘッダーのアクセスキーが存在しないか、無効です。認証を参照してください。
| コード | メッセージ | 説明 |
|---|---|---|
5 | error getting process: rpc error: code = NotFound desc = process not found | プロセス ID が見つからなかった場合。 |
レート制限に達しました。システムが HTTP 429 エラーを受信した場合、連鎖的な障害を防ぎ、制限の悪化を避けるためのメカニズムを実装する必要があります。
ベストプラクティス:
- クールダウン期間(バックオフ): システムからの後続のリクエストを直ちに停止または抑制してください。失敗したリクエストを短いループで継続的にリトライしないでください。
- キューイングとスロットリング: 送信リクエストをバッファリングまたはキューに入れて、再送信前にトラフィックフローを制御してください。
- ジッター付き指数バックオフ: リトライ時には、試行間の待機時間を指数的に増加させ(例: 1秒、2秒、4秒、8秒)、小さなランダムな遅延(「ジッター」)を追加して、キュー内のすべてのリクエストがまったく同じミリ秒にリトライするハードエフェクトを防止してください。
警告
バックオフを適用せずにレート制限されたエンドポイントにリクエストを送り続けると、制限期間が延長され、システムの運用スループットに深刻な影響を与える可能性があります。リクエストを適切にスロットリングすることで、よりスムーズで回復力のあるインテグレーションが実現します。
デフォルトの制限、リクエストの増加、その他の詳細については、レート制限を参照してください。
| コード | メッセージ | 説明 |
|---|---|---|
99999 | Internal failure! Try again later | 内部エラーが発生した場合。 |
次のステップ
- 新しいセルフィーを送信するには、プロセスの作成に戻ってください。
humanTokenが何を表すか、また生成されない場合については、Human Token の概要を参照してください。