/v1/me routes

These routes act on the one user who owns the token. Send the user token as Authorization: Bearer <jwt>.

export TOKEN="<user token from enroll or match>"

Get the profile

GET /v1/me

curl https://api.facecard.dev/v1/me -H "Authorization: Bearer $TOKEN"

Returns the profile, the enrollment date, the number of face templates and the consent record (policy version and time). It never returns descriptors.

Update the name

PATCH /v1/me with { "name": "Ada L." }. Only name can be changed this way.

curl -X PATCH https://api.facecard.dev/v1/me \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Ada L."}'

Change email

Changing the email is a two step flow.

1. POST /v1/me/email with { "new_email": "ada@new.example" }. FaceCard sends a 6 digit code to the new address. The code expires after 15 minutes.
2. POST /v1/me/email/confirm with { "code": "123456" } applies the change.

curl -X POST https://api.facecard.dev/v1/me/email \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"new_email":"ada@new.example"}'

curl -X POST https://api.facecard.dev/v1/me/email/confirm \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"code":"123456"}'

Errors: 409 email_taken if the new address already exists in this app, 400 invalid_code for a wrong or expired code.

Add templates

POST /v1/me/templates

Adds 1 to 3 more descriptors to the user's face templates after a fresh match. It needs a new challenge, the same as /v1/match. A user keeps at most 10 templates, and the oldest learned template is dropped first.

curl -X POST https://api.facecard.dev/v1/me/templates \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d @templates.json

templates.json holds challenge_id, descriptors (1 to 3 arrays of 128 floats) and liveness, as in match.

Sign out

POST /v1/me/logout

Ends this session on the server. The token's jti goes on a revocation list until the token would have expired anyway, and for first party apps the fc_session cookie is cleared. Returns 204 No Content. Send the token as a Bearer header or, for first party apps, in the fc_session cookie.

curl -X POST https://api.facecard.dev/v1/me/logout -H "Authorization: Bearer $TOKEN"

After that, the same token gets 401 token_revoked on every /v1/me route, and POST /v1/tokens/verify reports { "valid": false, "reason": "revoked" }. Calling logout again with the same token also returns 401 token_revoked, so treat 204 and 401 as "signed out". Other sessions of the same user keep working.

Offline verification cannot see a sign out. Checking a token against the public keys at /.well-known/jwks.json only proves the signature and expiry. A signed out token still passes that check until it expires (up to one hour). POST /v1/tokens/verify is the revocation aware check. Use it for anything sensitive, or keep your own session short.

Delete the account

DELETE /v1/me

Deletes the profile, every face template, the consent record and challenge rows for that user. It writes a tombstone auth event that contains no personal data. Returns 204 No Content. This cannot be undone.

curl -X DELETE https://api.facecard.dev/v1/me -H "Authorization: Bearer $TOKEN"

Errors