Face Authentication
Unregister
Removes a customer’s face registration so they can no longer authenticate until they enroll again.
Request
cus_user_id is the only required field.
| Name | Type | Required | Description |
|---|---|---|---|
cus_user_id | string | Required | User id of customer (max 256) |
device_id | string | Optional | Device id of user (max 256) |
app_id | string | Optional | App id of customer (max 128) |
lat | float | Optional | Latitude of device |
lng | float | Optional | Longitude of device |
{
"cus_user_id": string,
"device_id": string,
"app_id": string,
"lat": float,
"lng": float,
}
Sample request
curl -X POST \
https://tv-staging.trustingsocial.com/api/v1/face_auth_unregister \
-H 'Authorization: TV <YOUR ACCESS KEY>:<CREATED SIGNATURE>' \
-H 'X-TV-Timestamp: 2019-04-21T18:00:15+07:00' \
-H 'Content-Type: application/json' \
-d \
'
{
"cus_user_id": "3b4bf7b6-088b-4931-9279-9259f5c34fe3",
}
'
Response
data.status carries the verdict: an HTTP 200 means the request finished processing, not that the user was unregistered, so read data.status — it is either "success" or "failure", and on "failure" the errors field tells you why. The nested user block is the shared face_auth_user record as it stands after unregistration, and errors is the shared error envelope.
{
"data": {
"status": string, // "success" or "failure"
"unregister_id": string, // id of this unregistration request
"face_auth_user": { // user information after unregistration
"id": string,
"client_id": string,
"access_key_id": string,
"face_auth_id": string,
"id_card_face_id": string,
"cus_user_id": string,
"device_id": string,
"app_id": string,
"latitude": float,
"longitude": float,
"metadata": json_object,
"is_deactivated": bool,
"is_unregistered": bool,
"created_at": string_time,
"updated_at": string_time
}
},
"errors": [
{
"code": string,
"message": string,
"detail": {
"field": string, // optional, which parameter is invalid.
... // any other information that can be useful for client
},
},
... // other errors
]
}
A successful unregistration looks like this:
{
"data": {
"status": "success",
"unregister_id": "d4f99f9b-4862-437f-a9c9-608e050d06c6",
"face_auth_user": {
"id": "f1ca6795-cbd4-4eec-821f-b4ac646db627",
"client_id": "0ef0f7e9-7f2f-4767-84b8-f76da7701c46",
"access_key_id": "c7d97b7c-f73d-4d62-973e-6eb3e0557ddf",
"cus_user_id": "3b4bf7b6-088b-4931-9279-9259f5c34fe3",
"face_auth_id": "",
"id_card_face_id": "4f959f4a-f5de-4b50-8724-224e709d06c2",
"live_face_id": "009161c9-9c89-4573-8119-8f513de4449c",
"device_id": "",
"app_id": "",
"latitude": 1.0,
"longitude": 2.0,
"metadata": {
"key1": "value1",
"key2": 2
},
"is_deactivated": false,
"is_unregistered": true,
"created_at": "2023-12-27T03:33:06.307977Z",
"updated_at": "2023-12-28T03:33:06.307977Z",
}
}
}
Failure codes
Unregistration defines no failure codes of its own. When data.status is "failure", the reason arrives in the errors array — see the error envelope. On any other error the data field comes back empty and the error code names the cause.
Transport, auth and rate-limit errors are the same on every call — see Common objects & errors.