Facial ID Reference Guide

FACEIO exposes the Facial ID through the resolved Promise returned by the client-side fio.js methods. The exact object contains more fields, but the important account-linking value is facialId.

If you pass a payload during enroll(), FACEIO can return that payload during future authentication. Keep the payload limited to values your application needs, and do not use client-side payload data as the only authorization check.

1. 1. Create a FACEIO application. Use the Getting Started guide and the FACEIO Console ↗ to configure your application, widget settings, and security options.
2. 2. Enroll the user. Follow the Integration Guide, then call enroll() after the user chooses to enable facial authentication and grants the required browser permissions.
3. 3. Store the returned facialId. Save it in your backend if you need to map FACEIO authentication to your local account model.
4. 4. Authenticate returning users. Call authenticate() and compare the returned facialId with the account or session your application expects.
5. 5. Keep the backend synchronized. Use webhooks when enrollment, authentication, or Facial ID deletion events should update account state, audit logs, or risk controls.
6. 6. Delete when needed. Use /deletefacialid when a user revokes consent, deletes their account, disables biometric login, or requests removal.

The selected facial recognition engine maps an enrolled user's face into a mathematical feature vector used for future matching. FACEIO returns the Facial ID so your application can reference the enrolled record inside its own account workflow.

FACEIO itself, including fio.js, the embedded widget, the REST API, and the Console, does not store, handle, or have access to biometric hashes. The facial recognition engine selected by the application owner manages those hashes according to the engine choice, region, consent flow, and deletion policy.

Use the FACEIO Console ↗ to create a test application and validate which engine and security settings fit your user experience, account flow, and deployment requirements.

A facial vector, also called a biometric hash, is an array of floating-point values produced by the selected recognition engine during enrollment. FACEIO does not expose that biometric hash to your application through fio.js; your application receives the Facial ID and related response fields.

Do not treat a Facial ID as a public profile identifier or expose it in browser logs, analytics events, public support threads, or URLs. If you store it locally, store it server-side with the same care you apply to authentication-related account data.

For privacy planning, combine this reference with the Privacy Best Practices, Security Best Practices, and Trust Center.

• Store it with account data. Save the returned facialId in your backend when you need to link FACEIO to a local user record.
• Do server-side checks. Use the returned Facial ID as an input to your authorization logic, not as a standalone session grant.
• Keep payloads minimal. If you attach a payload during enrollment, include only data your authentication flow actually needs.
• Synchronize with webhooks. Use webhook events when changes to enrollment or deletion state must reach your backend.
• Offer user controls. Give enrolled users a path to disable biometric login or request Facial ID deletion.
• Document retention. Define when Facial IDs are kept, deleted, or unlinked in your product and privacy notices.

Facial ID deletion is performed through the FACEIO REST API using the /deletefacialid endpoint. Provide the Facial ID you want to remove from the target application using the supported REST API request format documented in the REST API reference.

After successful deletion, that enrolled Facial ID can no longer be used to authenticate the user. If the same user later chooses to enroll again, FACEIO creates a new enrollment record and returns a new Facial ID.