Frequently Asked Questions

FACEIO is a cross-browser facial authentication framework for web and mobile applications. Developers use it to add face recognition login, passwordless authentication, and account re-authentication without building the recognition pipeline themselves.

Integration starts with fio.js, the browser-side JavaScript library documented in the FACEIO Integration Guide. Users enroll and authenticate through a hosted widget that works with a webcam or mobile front camera.

FACEIO is developed and maintained by PixLab ↗, part of Symisc Systems ↗. FACEIO provides cross-browser facial authentication, the ID Match selfie-to-ID portrait comparison widget, and Meeting Shield for supported browser-based meetings. These are separate products with different purposes.

For privacy, security, and operating practices, start with the Trust Center, privacy best-practice guide, and security best-practice guide.

1. Create an application in the FACEIO Console ↗.
2. Copy your application Public ID.
3. Add fio.js to your website or web app.
4. Call enroll() for user registration and authenticate() for returning user login.

The shortest path is the Getting Started guide. For production code, continue with the fio.js API reference and integration guide.

FACEIO combines several pieces: the fio.js JavaScript SDK, a secure browser widget, backend facial authentication services, optional REST APIs, and webhook events for your server.

Most facial-authentication integrations start with the hosted widget because it handles camera capture, liveness checks, face matching, and browser compatibility. The widget presents the configured consent flow, while the application owner remains responsible for notices and consent. Applications can then connect webhooks, REST API endpoints, and Facial ID workflows.

Yes. FACEIO is designed for modern desktop and mobile browsers that can access a webcam or front-facing camera. Use the same fio.js pattern for desktop and mobile web flows, then test camera permissions and browser behavior before release.

For browser and framework notes, review the Developer Center and the integration guide.

• Getting Started for the first application and quick setup.
• Integration Guide for fio.js, enroll(), authenticate(), error handling, and session handling.
• Developer Center for framework examples, REST APIs, webhooks, privacy, security, and production references.
• Webhooks and Facial ID for backend synchronization and enrolled-user lifecycle management.

FACEIO is framework agnostic. You can load fio.js from plain HTML, React, Vue, Next.js, Angular, jQuery, or any frontend that can run browser JavaScript and request camera permission.

Your backend can be written in Node.js, PHP, Python, Go, Rust, Java, .NET, or any stack that can receive webhooks and make HTTPS requests to the REST API. Start with the Developer Center and integration guide.

Yes. FACEIO can be used as a passwordless face login layer, a second-factor verification step, or an account re-authentication step before sensitive actions. The right pattern depends on your session model, account recovery flow, and user consent requirements.

For planning, compare the passwordless authentication guide, the face login guide, and the security best-practice documentation.

Yes. FACEIO webhooks let your backend receive user enrollment, successful authentication, and Facial ID deletion events. This is useful when your server needs to synchronize account state, write audit logs, or trigger application workflows.

Validate the WWW-Authenticate bearer token and expected application identifiers before you trust a webhook payload.

A Facial ID, also called an Index ID, is the FACEIO identifier associated with an enrolled user's face authentication record. It helps developers manage authentication state, deletion requests, and account-linking logic without exposing raw face images, facial vectors, or biometric hashes to the application.

The REST API is for private backend operations such as managing application data, working with Facial IDs, and deleting enrolled records. It is separate from widget instantiation through fio.js, which runs in the user's browser.

Retrieve your API key from the Application Manager in the FACEIO Console ↗, keep it server-side, and review the REST API documentation before making production calls.

A Facial ID is an anonymous unique identifier, similar in purpose to a UUID ↗, assigned by the selected facial recognition engine to each enrolled user in your FACEIO application after explicit consent. It helps your backend map face authentication to your own account records while keeping user-facing account data separate from the facial recognition engine index.

Facial enrollment is created with a single call to enroll() from fio.js, the JavaScript widget library implemented on your website or web application.

To delete a Facial ID, make a REST API call from your private backend to the DELETEFACIALID endpoint. A successful call purges the given Facial ID, associated payload data, and biometric hash from that FACEIO application. The endpoint is documented in the REST API reference.

A backend Python deletion example is available as a GitHub Gist ↗. For privacy and compliance practices, see the FACEIO Trust Center.

Yes. The Application Manager lets you adjust widget appearance, add your logo, configure legal links, and set security options for each FACEIO application. Keep the consent and legal links clear because they are part of the user-facing authentication flow.

Create or update widget settings from the FACEIO Console ↗, then test the flow in the browsers and devices your users actually use.

The facial recognition engine maps an enrolled user's face into a mathematical feature vector, commonly handled as a biometric hash inside a sandboxed application index. FACEIO supports PixLab Insight and AWS Rekognition, with engine selection, region choice, and deployment model configured by the application owner.

Choose based on data residency, cloud provider requirements, on-premise needs, and your legal/security review. Use the Facial ID reference, privacy best-practice guide, security best-practice guide, and the FACEIO Console ↗ to test the setup.

FACEIO supports cloud facial-recognition engines and an on-premises deployment option using PixLab Insight inside customer-controlled infrastructure. The application owner selects and configures the engine, region, credentials, and deployment model. Contact the team through the FACEIO Console support channel ↗ for deployment planning.

FACEIO Meeting Shield is a Chrome extension that evaluates deepfake and synthetic-video risk signals in Google Meet, Zoom Web, Microsoft Teams Web, and Cisco Webex browser meetings. Extensions for Microsoft Edge and Firefox are in development and scheduled for release in 2027. It is separate from fio.js facial authentication and does not guarantee that every manipulated video will be detected.

FACEIO ID Match is an embeddable browser widget. Integrators call idmatch() to capture a live selfie and an ID, run liveness checks, and compare the selfie with the portrait on the document.

FACEIO powers face detection, liveness, and 1:1 face matching. PixLab's DOCSCAN API endpoint ↗ scans the ID and can optionally extract document fields. ID Match does not authenticate the document, establish legal identity, complete KYC or AML checks, or make an approval decision.

Standard FACEIO facial authentication enrolls a user and later authenticates that returning user against the enrolled record. ID Match does not enroll or authenticate the person. It performs a one-time 1:1 comparison between a live selfie and the portrait on a presented ID and can optionally return extracted document fields.

Implementation follows the same fio.js pattern described in the integration guide, but the ID Match flow calls idmatch() instead of enroll() or authenticate().

Use the FACEIO Console ↗ to create applications, copy Public IDs, configure widget appearance, manage security options, review usage, open support tickets, and manage billing.

For public plan details, see the FACEIO pricing page.

FACEIO offers plans suitable for prototypes, MVPs, and production applications. Check the pricing page for current limits, features, and upgrade options, then create or update your app from the Console ↗.

Sign in to the FACEIO Console ↗, select New Application, follow the wizard, then use the generated Public ID in your fio.js integration.

The Getting Started guide walks through the same process with the minimum code needed to enroll and authenticate your first user.

Create an account from the FACEIO Console sign-up page ↗, then create your first application from the dashboard. Verification steps are handled inside the Console as part of application setup.

To close an account, remove applications that are no longer needed, clear any active subscription requirements, then use the account controls or private support in the Console support channel ↗. Account deletion is permanent, so export anything you need before requesting closure.

FACEIO does not store full credit card details in the application Console. Payments and subscription handling are processed by the merchant or payment processor shown during checkout where applicable.

For plan changes, invoices, and private billing questions, use the Console support channel ↗.

The application owner is responsible for how FACEIO is used inside their product. That includes when the widget is shown, what users are told, how consent is collected, which recognition engine is selected, which security options are enabled, and what happens after FACEIO returns an authentication result.

FACEIO is a production-hardened facial authentication framework deployed since 2022, with more than 9 million widget instances served and thousands of customers around the globe. That production history does not replace your own application-level security, privacy, legal, and user-consent responsibilities.

FACEIO provides the browser widget, APIs, webhooks, and implementation guidance. It is not responsible for an application's misuse, missing user notices, weak account recovery, unsafe session handling, or downstream decisions made by the application. Before launch, review the security best-practice guide, privacy best-practice guide, and Trust Center.

No. FACEIO itself, including fio.js, the embedded widget, the REST API, and the Console, does not retain raw face images or store or expose biometric hashes. Your application receives identifiers and authentication results, not raw face images, facial vectors, or biometric hashes.

The selected facial recognition engine handles facial vectors or hash signatures according to the application owner's configuration, region, consent flow, and deletion policy. Application owners are responsible for selecting the engine, explaining the flow to users, and providing deletion or opt-out paths. Read the Facial ID reference, privacy best-practice guide, and Trust Center.

No. FACEIO itself does not store biometric hashes. The selected facial recognition engine creates and handles a biometric hash only through the enrollment flow after explicit user consent. A biometric hash is a mathematical feature vector; it is not a raw face image and is not returned to your frontend.

Each FACEIO application uses its own sandboxed index. There is no centralized biometric-hash database for customers, and deletion workflows are handled through the documented Facial ID and REST API flows. Application owners remain responsible for lawful notices, consent, retention choices, and user deletion requests.

No. FACEIO liveness and anti-spoofing checks are part of the facial authentication flow, but no detection system can guarantee that every presentation attack, replay attempt, automation attempt, or account-abuse pattern will be blocked.

Application owners should combine FACEIO with the default PIN Code validation, domain restrictions, rate limiting, account recovery rules, server-side authorization checks, webhook validation, and appropriate support processes. Use the security best-practice guide to decide which controls belong in your application.

FACEIO enables PIN Code validation by default. The PIN adds a user-known secret to facial authentication, so the configured flow requires more than a face match. The PIN is an additional authentication factor, not a deepfake detector, and should be combined with liveness checks and application-level security controls.

Application owners can review PIN Code requirements, weak PIN rejection, domain restrictions, country restrictions, and other security controls from the Application Manager in the FACEIO Console ↗. The recommended configuration is documented in the security best-practice guide.

Yes. Application owners can restrict widget instantiation to approved domain names and, where configured, approved countries. These controls help prevent unauthorized websites from loading your FACEIO application and reduce unwanted traffic from regions you do not serve.

Configure these options in the SECURITY tab of the Application Manager and verify the behavior before production rollout. See the security best-practice guide for deployment guidance.

Start with the Trust Center, privacy best-practice guide, and security best-practice guide. Product, legal, and engineering teams should also review the Privacy Policy and Terms of Service before deploying FACEIO to real users.

FACEIO documentation helps teams implement facial authentication responsibly, but it is not a substitute for the application owner's own legal review, security review, user notices, consent flow, support process, or compliance obligations in the markets where their application operates.

Use the FACEIO Community Forum ↗ for public implementation questions, developer discussions, and long-tail topics that can help other teams integrating facial authentication.

Use the Console support channel ↗ for private account, billing, production, security, or customer-specific issues.

Use the forum for reusable questions such as framework examples, integration patterns, webhook handling, face login UX, ID Match implementation, and troubleshooting notes that do not expose private account data.

Use private support when the issue includes application IDs, billing details, user data, production incidents, or security-sensitive information.

Use the FACEIO status page ↗ for current service availability and incident updates. For implementation help, use the support page or open a private request from the Console.