

YOUR DEVELOPER ACCOUNT

Account Info & Encryption Keys
Demo Session Dashboard

 API Reference 
Search Docs...
DEVELOPER GUIDES

Guide
Architecture: Features & Options
Compatibility: Devices & Server
UX, Themes & Branding
The
Text FaceTec
& LanguageAPIEditing
provides a variety of functions for processing
a Liveness
OCR Check,
Templates Enrollment, Re-VeriBcation, Identity Checks,
& Creator
Age Checks, and Image Comparisons.
DEVICE SDK DETAILS
Getting Started
GET /status
Download SDKs
New Release Info & Notes
Retrieves important
Reducing Device SDK information
Size about the Server SDK.
API OVERVIEW
Parameters
API Reference Guide
API
NoneCall List
Testing API
Postman Test Suite
Core Response Properties
BIOMETRIC CYBERSECURITY
running:
FaceTec'sBoolean
Best Practices
success: BooleanEncryption
3D FaceScan/Map
Audit Trail ImagesBoolean
wasProcessed:
Client-Side Device Security
error: Boolean
3D FaceMap Interoperability
serverInfo: JSON String (includes the Server SDK Version,
UR Codes - Biometric Barcodes
Type, and Mode)
METRICS & SPECS
World-Leading Face Matching
POST /liveness-3d
Technical & Hardware Details
3D Liveness Checks (Paid)
Performs
3D:3D FaceaMatching
Liveness(Free)
Check on the FaceScan. See 3D Liveness
Checks Guide./ NFC Match (Free)
3D:2D Portrait
3D:2D Photo ID Matching (Free)
3D:2D 3rd-Party ID Image (Free)
Parameters
3D:2D ProBle Pic Matching (Free)
3D:2D KioskFaceScan
faceScan: POS Matching (Free)
ID Document Anti-Tampering
auditTrailImage: (Free)
Base64 Image
OCR Photo ID Document (Free)
lowQualityAuditTrailImage: Base64 Image
Barcode & NFC Scanning (Free)
1:N De-duplication Checks (Free)
Core Response
Age Check Properties
from 3D SelBe (Free)
3D FaceVectors: No Images (Free)
success: Boolean
2D Single-Frame Liveness (Free)
scanResultBlob: Scan Result Blob
2D Image Guidelines
Success Rates, Biases & Diversity
Additional Response Properties
GOING PRODUCTION
Overview
ageV2GroupEnumInt: 0 = Age estimate not available, 1 = Age
SDK Encryption Keys
Under 8, 2 = Age Over 8, 3 = Age Over 13, 4 = Age Over 16, 5 =
Usage Logs Guide
Age Over
Server SDK18, 6 = Age Over
Integration 21, 7 = Age Over 25, 8 = Age Over 30
Guides
platformTypeEnumInt: Platform (Android/iOS/Browser) Type
HELP & SUPPORT
(int)
FAQ
deviceSDKVersion: Version (String)
Videos
Technical Support
Success Criteria
Request Pricing Quote
Glossary
success is true if ALL of the following are true:

1. The FaceScan came from a Live Human and Liveness

was Proven. The result of the 3D Liveness Check itself
can be checked on the
[Link]
_ag.
2. The Session Token was valid and not expired. The result
of the Session Token Check itself can be checked on the
[Link]
_ag.
3. The Audit Trail Image came from the same Session as the
FaceScan and the Audit Trail Image Matches the User in
the FaceScan. The result of the Audit Trail VeriBcation
Check itself can be checked on the
[Link]
_ag.
4. The FaceScan was not a replay (if conBgured. On by
default in the Server SDK). The result of the Replay Attack
Check itself can be checked on the
[Link] _ag.

POST /enrollment-3d
Performs a Liveness Check on the FaceScan and stores the
resulting 3D FaceMap in the database on success. See 3D:3D
Face Matching.

Parameters
faceScan: FaceScan
auditTrailImage: Base64 Image
lowQualityAuditTrailImage: Base64 Image
externalDatabaseRefID: String (More Information)
storeAsFaceVector: Boolean (Optional)

Response
success: Boolean
scanResultBlob: Scan Result Blob

Additional Response Properties

ageV2GroupEnumInt: 0 = Age estimate not available, 1 = Age
Under 8, 2 = Age Over 8, 3 = Age Over 13, 4 = Age Over 16, 5 =
Age Over 18, 6 = Age Over 21, 7 = Age Over 25, 8 = Age Over 30
platformTypeEnumInt: Platform (Android/iOS/Browser) Type
(int)
deviceSDKVersion: Version (String)

Success Criteria
success is true if ALL of the following are true:

1. The FaceScan came from a Live Human and Liveness

was Proven. The result of the 3D Liveness Check itself
can be checked on the
[Link]
_ag.
2. The Session Token was valid and not expired. The result
of the Session Token Check itself can be checked on the
[Link]
_ag.
3. The Audit Trail Image came from the same Session as the
FaceScan and the Audit Trail Image Matches the User in
the FaceScan. The result of the Audit Trail VeriBcation
Check itself can be checked on the
[Link]
_ag.
4. The FaceScan was not a replay (if conBgured. On by
default in the Server SDK). The result of the Replay Attack
Check itself can be checked on the
[Link] _ag.
5. The externalDatabaseRefID was a valid String and did not
already exist in the Database.
a. The storage of the FaceMap to the Database succeeded
without error.

Notes
1. There is no Server Core API for Enrollment since
Enrollment requires a Database, which Developers control
and own in the FaceTec Server SDK.

GET /enrollment-
3d/:externalDatabaseRefID
Retrieve an enrolled 3D FaceMap. See Using
externalDatabaseRefID in API Calls (HTTPS API).

Parameters
externalDatabaseRefID: String (More Information)
storeAsFaceVector: Boolean (Optional)

Response
success: Boolean
faceMapBase64: Base64 FaceMap
auditTrailBase64: Base64 Image

POST /match-3d-3d
Processes a FaceScan for Liveness and Matches it against a
Liveness-proven 3D FaceMap. See 3D:3D Face Matching.

Parameters
faceScan: FaceScan
auditTrailImage: Base64 Image
lowQualityAuditTrailImage: Base64 Image
externalDatabaseRefID: String (More Information)

Response
success: Boolean -- the 3D Liveness Check + 3D:3D Match is
successful if and only if this Boolean Qag is true.

Additional Response Properties

ageV2GroupEnumInt: 0 = Age estimate not available, 1 = Age
Under 8, 2 = Age Over 8, 3 = Age Over 13, 4 = Age Over 16, 5 =
Age Over 18, 6 = Age Over 21, 7 = Age Over 25, 8 = Age Over 30
platformTypeEnumInt: Platform (Android/iOS/Browser) Type
(int)
deviceSDKVersion: Version (String)

Success Criteria
success is true if ALL of the following are true:

1. The FaceScan came from a Live Human and Liveness

was Proven. The result of the 3D Liveness Check itself
can be checked on the
[Link]
_ag.
2. The Session Token was valid and not expired. The result
of the Session Token Check itself can be checked on the
[Link]
_ag.
3. The Audit Trail Image came from the same Session as the
FaceScan and the Audit Trail Image Matches the User in
the FaceScan. The result of the Audit Trail VeriBcation
Check itself can be checked on the
[Link]
_ag.
4. The FaceScan was not a replay (if conBgured. On by
default in the Server SDK). The result of the Replay Attack
Check itself can be checked on the
[Link] _ag.
5. The externalDatabaseRefID was a valid String and already
exists in the Database.
a. The FaceScan was Matched against a Liveness-Proven
3D FaceMap from the Database and Matched at Match
Level 15.
7. A Continuous Learning FaceMap was produced and
stored in the Database.

POST /match-3d-2d-idscan
Processes a FaceTec ID Scan against a Liveness-proven 3D
FaceMap. Only works with the Device SDK ID Scan Session.
See Photo ID Matching Guide.

Parameters
idScan: IDScan
idScanFrontImage: Base64 Image
idScanBackImage: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean (Please Note: success == true if the
processing of the particular IDScan step was completed
without error. This boolean should not be used to query for
success of the overall state of the in-progress IDScan).
isCompletelyDone: Boolean
photoIDNextStepEnumInt: 0 = FRONT_RETRY, 1 = BACK, 2 =
BACK_RETRY, 3 = USER_CONFIRM, 4 = COMPLETE, 5 = NFC
matchLevel: Match Level
scanResultBlob: Scan Result Blob
documentData: JSON String

Additional Response Properties

faceMapAgeV2GroupEnumInt: 0 = NOT_AVAILABLE, 1 =
UNDER8, 2 = OVER8, 3 = OVER13, 4 = OVER16, 5 = OVER18, 6 =
OVER21, 7 = OVER25, 8 = OVER30
idScanAgeV2GroupEnumInt: 0 = NOT_AVAILABLE, 1 =
UNDER8, 2 = OVER8, 3 = OVER13, 4 = OVER16, 5 = OVER18, 6 =
OVER21, 7 = OVER25, 8 = OVER30
idScanSessionID: String (UUID)
matchLevelNFCToFaceMap: MatchLevel
fullIDStatusEnumInt: 0 = FULL_ID_DETECTED, 1 =
COULD_NOT_CONFIDENTLY_DETERMINE_FULL_ID_USER_NEEDS_TO_RETRY
digitalIDSpoofStatusEnumInt: 0 = LIKELY_PHYSICAL_ID, 1 =
COULD_NOT_CONFIDENTLY_DETERMINE_PHYSICAL_ID_USER_NEEDS_TO_RETRY
watermarkAndHologramStatusEnumInt: 0 = NOT_AVAILABLE,
1 = DETECTED, 2 = WAS_NOT_DETECTED
nfcStatusEnumInt: 0 = NO_NFC_SPECIFIED_BY_TEMPLATE, 1
= NFC_REQUESTED_BUT_DEVICE_NOT_CAPABLE, 2 =
NFC_REQUESTED_BUT_USER_PRESSED_SKIP, 3 =
NFC_REQUESTED_BUT_ERROR_ACCESSING_CHIP, 4 =
SUCCESS, 5 = NFC_REQUESTED_BUT_ERROR_READING_MRZ
nfcAuthenticationStatusEnumInt: 0 = NOT_APPLICABLE, 1 =
NOT_SUPPORTED_BY_DOCUMENT, 2 =
NOT_SUPPORTED_BY_SDK, 3 = FAILED, 4 = AUTHENTICATED,
5 = FAILED_DUE_TO_SIGNATURE_VERIFICATION
mrzStatusEnumInt: 0 = NO_MRZ_SPECIFIED_BY_TEMPLATE, 1
= MRZ_READ_BUT_CHECKSUM_FAILED, 2 = SUCCESS
barcodeStatusEnumInt: 0 =
NO_BARCODE_SPECIFIED_BY_TEMPLATE, 1 =
BARCODE_REQUESTED_BUT_NOT_FOUND, 2 =
BARCODE_REQUESTED_BUT_ERROR_READING, 3 = SUCCESS,
4=BARCODE_REQUESTED_AND_READ_BUT_COULD_NOT_PARSE
faceOnDocumentStatusEnumInt: 0 = NOT_AVAILABLE, 1 =
LIKELY_ORIGINAL_FACE, 2 =
CANNOT_CONFIRM_ID_IS_AUTHENTIC, 3
= OCR_TEMPLATE_DOES_NOT_SUPPORT_DETECTION
textOnDocumentStatusEnumInt: 0 = NOT_AVAILABLE, 1 =
LIKELY_ORIGINAL_TEXT, 2 =
CANNOT_CONFIRM_ID_IS_AUTHENTIC
isReadyForUserConXrmation: Boolean
didCompleteIDScanWithoutMatching: Boolean
didCompleteIDScanWithoutMatchingOCRTemplate: Boolean
didCompleteIDScanWithUnexpectedMedia: Boolean
unexpectedMediaEncounteredAtLeastOnce: Boolean
didMatchIDScanToOCRTemplate: Boolean
scannedIDPhotoFaceFoundWithMinimumQuality: Boolean

Additional Data (Not Added to Response)

Note: The Additional Data Base64 Images are stored in Your
FaceTec Server Database and not in the Default API Response.
This is by design to keep the Network Load to a minimum and
prevent the API Performance and Response Time from being
negatively impacted. You must add code to the FaceTec Server
SDK to modify this behavior, but FaceTec does not recommend
doing this.

photoIDFaceCrop: Base64 Image

photoIDFrontCrop: Base64 Image
photoIDBackCrop: Base64 Image
extractedNFCImage: Base64 Image
photoIDPrimarySignatureCrop: Base64 Image
photoIDSecondarySignatureCrop: Base64 Image
photoIDTamperingEvidenceFrontImage: Base64 Image
photoIDTamperingEvidenceBackImage: Base64 Image

Success Criteria

Important Note: Please take careful note of the

Success Criteria. FaceTec's ID Scan Process is
designed to let Users through the process despite not
passing all _ags that are returned. You are
responsible for processing the response
_ags/checks and making decisions based on your
business requirements. If you would like to Force the
User to Retry until a particular _ag/check is
successful, please use the Force Retry API. Please
also note that while FaceTec's ID Scan Process
performs a variety of strong checks to determine that
the Document is physically present (not a Digital
Spoof) and has not had Tampering performed,
FaceTec does not "Authenticate IDs." Please see this
guide for more details.

The ID Scan is considered done and successful if all of the

below are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The externalDatabaseRefID was a valid String and already
exists in the Database.
3. The 3D FaceMap was Matched against the ID Scan at
minMatchLevel or greater.
4. A Full ID was detected during the ID Scan capture
process. Please note the fullIDStatusEnumInt is not a
security feature; its purpose is to provide additional
consistency to the capture process for optimal ID Scan. In
some scenarios, the ID may not be 100% visible due to
how the user holds it or in cases where the ID is
presented inside a plastic case. These are considered
valid Sessions and should not be rejected or trigger a
retry if the OCR results are correct.
5. The DigitalIDSpoofStatus was Physical ID. If the
DigitalIDSpoofStatus was not Physical ID then this does
not necessarily indicate the ID Scan was a Spoof. It could
also indicate the User provided a poor or incomplete scan
of the ID. If the DigitalIDSpoofStatus was NeedsRetry but
the idScanFrontImage looks like quality data from a Full
ID, the User will likely succeed on Retry when they provide
slightly better data.
a. isCompletelyDone equals true indicates the User
ConBrmation step has been completed. Please note that
the User ConBrmation step can be skipped using custom
code server-side code. In this scenario, you will know
when the ID Scan process is complete based on your own
criteria.
7. didMatchIDScanToOCRTemplate equals true indicates
that the FaceTec SDK could match the ID Scan to any
installed OCR Template with high conBdence. If false, it is
required for the User to Retry to provide higher quality
data or a different ID.

Notes
1. In the HTTPS API, an externalDatabaseRefID is used
rather than passing in a FaceMap or FaceScan directly.
This is because the Photo ID Match _ow Brst requires a
User to Prove Liveness, then requires the User to get a
quality scan of their ID. There will be Users that need to
Retry their ID Scans due to an error scanning their Brst
time. The FaceTec Sample App shows how you keep a 3D
FaceMap "Enrolled" so that your backend servers have
access to the 3D FaceMap for these repeated attempts.
The 3D FaceMap is looked up / retrieved by the
externalDatabaseRefID.
2. Match Level 7 (99.9998%) is the maximum Match Level
returned.
3. minMatchLevel allows Developers to specify a Match
Level that they would like to target for matching to
succeed. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.
4. Full IDs and Physical IDs are required for success to be
true.
5. A Match Level will not be returned unless FaceTec SDKs
assess the ID to be Full, and Physical, and the User does
not need to Retry.
a. idScanSessionID identiBes the Session used to
perform a given 3D:2D Match. You can look for all 3D:2D
Matches performed during the same User Session by
querying against idScanSessionID .
7. If the FullIDStatus is not FullID, it does not mean the SDK
assessed that the ID was incomplete. It could be
incomplete, but it could also be a scan that needs to be
made better, and thus a Retry usually resolves the issue.
p. If the DigitalIDSpoofStatus is not a Physical ID, it does not
mean the SDK assessed that the ID was a Spoof. It could
be a Spoof, but it could also be a scan that needs to be
made better, and thus a Retry usually resolves the issue.
9. If DigitIDSpoofStatus or matchLevel are preventing the ID
Scan from succeeding, the ID Scan will be allowed to
continue to completion after 3 failed attempts where
these are the only _ags that are rejecting, to get the User
to completion through the _ow.
10. If the FaceOnDocumentStatus is not "Likely Original Face",
it does not mean that the SDK assessed that the ID's face
photo was modiBed or replaced. It could be a doctored
image, but it could also be a scan that could be made
better with a Retry. Note that IDs with "Likely Original
Face" are not required for success to be true, but you may
conBgure the SDK to force a retry based on your own
success criteria.
11. If the TextOnDocumentStatus is not "Likely Original Text",
it does not mean that the SDK assessed that the ID's
text was modiBed or replaced. It could be doctored, but it
could also be a scan that could be made better with a
Retry. Note that IDs with "Likely Original Text" are not
required for success to be true, but you may conBgure the
SDK to force a retry based on your own success criteria.
12. photoIDTamperingEvidenceFrontImage and photoIDTa
mperingEvidenceFrontImage are returned when either f
aceOnDocumentStatus or textOnDocumentStatus is
“CannotConBrmIDIsAuthentic”. These are images of the
ID with red ellipses around example areas where
tampering was detected.
13. didCompleteIDScanWithoutMatchingOCRTemplate is a
boolean to indicate that the ID Scan was completed
without attempting to match an OCR Template.
14. Note that the ID Scan can visibly look "good enough", but
could reject certain under-the-hood checks. In this case,
the User will likely succeed on a quick Retry when they
provide slightly better additional data.
15. The documentData object is a JSON String that contains
extracted NFC, Barcode, OCR, and User ConBrmed data.
1a. The documentData object contains extracted NFC signing
certiBcate data on NFC scans.
17. Check out the v9.4.0 Release Notes for more information
on OCR, Barcode, and NFC capabilities.
1p. The photoIDNextStep is a variable returned during ID
Scan Sessions that allows Customers and Partners to
customize the ID Scan behavior and determine the next
steps for a particular ID Scan Session according to their
business logic.
0 = FRONT_RETRY - This indicates the Front of the
Document captured during the ID Scan Session
was _agged and a Retry is needed. Ex: Front ID not
fully detected, the ID could not be recognized,
expected media not found, ID Tampering detected,
etc.
1 = BACK - Only returned after successfully
scanning the Front of the Document, indicates the
Document is marked for Backside scanning, and
the Back of the Document is ready to be captured.
2 = BACK_RETRY - Indicates the Backside of the
Document captured during the ID Scan Session
was _agged and a Retry is needed. Ex: Back of ID
not fully detected, the ID could not be recognized,
expected media not found, ID Tampering detected,
etc.
3 = USER_CONFIRM - After successfully scanning
the Front and the Back of a document marked for
backside scanning, this indicates the User
ConBrmation Screen will be displayed for the User
to verify the OCR Data and make small
adjustments if needed. See ID Scan: Logic &
Behavior Customization Guide for details about the
User ConBrmation Screen and how it can be
disabled.
4 = COMPLETE - The ID Scan Session was
completed. Please note that completing an ID
Scan Session does not mean the User should be
allowed to proceed. Customers and Partners are
required to implement their own logic to determine
success and the next steps based on the Session
Response Data for an ID Scanning Experience that
best re_ects their business requirements.
5 = NFC - For the Supported Documents and OCR
Templates, indicate the Front, and Back of the
Document, if marked for backside scanning, were
successfully processed, and scanning the NFC
Chip of the document is the next step.

POST /idscan-only
Processes a FaceTec ID Scan. Only works with the Device SDK
ID Scan Session. See Photo ID Matching Guide.

Important Note: Completion of this API Call does not

necessarily indicate that the ID is "valid" or that OCR
was Successful. Developers are responsible for
interpreting the results in the Response Properties to
make this determination.

Parameters
idScan: IDScan
idScanFrontImage: Base64 Image
idScanBackImage: Base64 Image

Response
success: Boolean
scanResultBlob: Scan Result Blob
documentData: JSON String

Additional Response Properties

idScanAgeV2GroupEnumInt: 0 = NOT_AVAILABLE, 1 =
UNDER8, 2 = OVER8, 3 = OVER13, 4 = OVER16, 5 = OVER18, 6 =
OVER21, 7 = OVER25, 8 = OVER30
idScanSessionID: String (UUID)
fullIDStatusEnumInt: 0 = FULL_ID_DETECTED, 1 =
COULD_NOT_CONFIDENTLY_DETERMINE_FULL_ID_USER_NEEDS_TO_RETRY
digitalIDSpoofStatusEnumInt: 0 = LIKELY_PHYSICAL_ID, 1 =
COULD_NOT_CONFIDENTLY_DETERMINE_PHYSICAL_ID_USER_NEEDS_TO_RETRY
watermarkAndHologramStatusEnumInt: 0 = NOT_AVAILABLE,
1 = DETECTED, 2 = WAS_NOT_DETECTED
nfcStatusEnumInt: 0 = NO_NFC_SPECIFIED_BY_TEMPLATE, 1
= NFC_REQUESTED_BUT_DEVICE_NOT_CAPABLE, 2 =
NFC_REQUESTED_BUT_USER_PRESSED_SKIP, 3 =
NFC_REQUESTED_BUT_ERROR_ACCESSING_CHIP, 4 =
SUCCESS, 5 = NFC_REQUESTED_BUT_ERROR_READING_MRZ
nfcAuthenticationStatusEnumInt: 0 = NOT_APPLICABLE, 1 =
NOT_SUPPORTED_BY_DOCUMENT, 2 =
NOT_SUPPORTED_BY_SDK, 3 = FAILED, 4 = AUTHENTICATED,
5 = FAILED_DUE_TO_SIGNATURE_VERIFICATION
mrzStatusEnumInt: 0 = NO_MRZ_SPECIFIED_BY_TEMPLATE, 1
= MRZ_READ_BUT_CHECKSUM_FAILED, 2 = SUCCESS
barcodeStatusEnumInt: 0 =
NO_BARCODE_SPECIFIED_BY_TEMPLATE, 1 =
BARCODE_REQUESTED_BUT_NOT_FOUND, 2 =
BARCODE_REQUESTED_BUT_ERROR_READING, 3 = SUCCESS,
4=BARCODE_REQUESTED_AND_READ_BUT_COULD_NOT_PARSE
faceOnDocumentStatusEnumInt: 0 = NOT_AVAILABLE, 1 =
LIKELY_ORIGINAL_FACE, 2 =
CANNOT_CONFIRM_ID_IS_AUTHENTIC, 3
= OCR_TEMPLATE_DOES_NOT_SUPPORT_DETECTION
textOnDocumentStatusEnumInt: 0 = NOT_AVAILABLE, 1 =
LIKELY_ORIGINAL_TEXT, 2 =
CANNOT_CONFIRM_ID_IS_AUTHENTIC
isCompletelyDone: Boolean
isReadyForUserConXrmation: Boolean
photoIDNextStepEnumInt: 0 = FRONT_RETRY, 1 = BACK, 2 =
BACK_RETRY, 3 = USER_CONFIRM, 4 = COMPLETE, 5 = NFC
didCompleteIDScanWithoutMatchingOCRTemplate: Boolean
didMatchIDScanToOCRTemplate: Boolean
scannedIDPhotoFaceFoundWithMinimumQuality: Boolean

Additional Data (Not Added to Response)

Note: The Additional Data Base64 Images are stored in Your
FaceTec Server Database and not in the Default API Response.
This is by design to keep the Network Load to a minimum and
prevent the API Performance and Response Time from being
negatively impacted. You must add code to the FaceTec Server
SDK to modify this behavior, but FaceTec does not recommend
doing this.

photoIDFaceCrop: Base64 Image

photoIDFrontCrop: Base64 Image
photoIDBackCrop: Base64 Image
extractedNFCImage: Base64 Image
photoIDPrimarySignatureCrop: Base64 Image
photoIDSecondarySignatureCrop: Base64 Image
photoIDTamperingEvidenceFrontImage: Base64 Image
photoIDTamperingEvidenceBackImage: Base64 Image

Success Criteria

Important Note: Please take careful note of the

Success Criteria. FaceTec's ID Scan Process is
designed to let Users through the process despite not
passing all _ags that are returned. You are
responsible for processing the response
_ags/checks and making decisions based on your
business requirements. If you would like to Force the
User to Retry until a particular _ag/check is
successful, please use the Force Retry API. Please
also note that while FaceTec's ID Scan Process
performs a variety of strong checks to determine that
the Document is physically present (not a Digital
Spoof) and has not had Tampering performed,
FaceTec does not "Authenticate IDs." Please see this
guide for more details.

The ID Scan is considered done and successful if all of the

below are true:

1. A Full ID was detected during the ID Scan capture

process. Please note the fullIDStatusEnumInt is not a
security feature; its purpose is to provide additional
consistency to the capture process for optimal ID Scan. In
some scenarios, the ID may not be 100% visible due to
how the user holds it or in cases where the ID is
presented inside a plastic case. These are considered
valid Sessions and should not be rejected or trigger a
retry if the OCR results are correct.
2. The DigitalIDSpoofStatus was a Physical ID. If the
DigitalIDSpoofStatus was not Physical ID then this does
not necessarily indicate the ID Scan was a Spoof. It could
also indicate the User provided a poor or incomplete scan
of the ID. If the DigitalIDSpoofStatus was NeedsRetry but
the idScanFrontImage looks like quality data from a Full
ID, the User will likely succeed on Retry when they provide
slightly better data.
3. The scannedIDPhotoFaceFoundWithMinimumQuality is
true. If scannedIDPhotoFaceFoundWithMinimumQuality is
false indicates that a face could not be found with
minimum quality on the Face Photo area deBned in OCR
Template.
4. The Session Token was valid and not expired. The result
of the Session Token Check itself can be checked on the
[Link]
_ag.
5. The Front and back Audit Trail Images came from the
same Session as the IDScan. The result of the Front and
Back Audit Trail VeriBcation Checks can be checked on
the
[Link]
and [Link]
_ag.
a. The IDScan was not a replay. The result of the Replay
Attack Check itself can be checked on the
[Link] _ag.
7. isCompletelyDone equals true indicates the User
ConBrmation step has been completed. Please note the
User ConBrmation step can be skipped using custom
code server-side code. In this scenario, you will know
when the ID Scan process is complete based on your own
criteria.
p. didMatchIDScanToOCRTemplate equals true indicates
the FaceTec SDK could match the ID Scan to any installed
OCR Template with high conBdence. If false, a Retry is
required to provide higher-quality data or a different ID.

Notes
1. Full IDs and Physical IDs are required for success to be
true.
2. idScanSessionID identiBes the Session used to
perform a given ID Scan. You can look for all ID Scans
performed during the same User Session by querying
against idScanSessionID .
3. If the FullIDStatus is not FullID, it doesn't mean the SDK
assessed the ID was incomplete. It could be incomplete,
but it could also be a scan that needs to be made better,
and thus a Retry usually resolves the issue.
4. If the DigitalIDSpoofStatus is not a Physical ID, it doesn't
mean the SDK assessed the ID was a Spoof. It could be a
Spoof, but it could also be a scan that needs to be made
better, and thus a Retry usually resolves the issue.
5. If DigitalIDSpoofStatus or matchLevel are preventing the
ID Scan from succeeding, ID Scan will be allowed to
continue to completion after 3 failed attempts where
these are the only _ags that are rejecting, to get the User
to completion through the _ow.
a. If the FaceOnDocumentStatus is not "Likely Original Face",
it doesn't mean the SDK assessed the ID's face photo was
modiBed or replaced. It could be a doctored image, but it
could also be a scan that could be made better with a
Retry. Note that IDs with "Likely Original Face" are not
required for success to be true, but you may conBgure the
SDK to force a retry based on your own success criteria.
7. If the TextOnDocumentStatus is not "Likely Original Text",
it doesn't mean the SDK assessed the ID's text was
modiBed or replaced. It could be doctored, but it could
also be a scan that could be made better with a Retry.
Note that IDs with "Likely Original Text" are not required
for success to be true, but you may conBgure the SDK to
force a retry based on your own success criteria.
p. photoIDTamperingEvidenceFrontImage and photoIDTa
mperingEvidenceFrontImage are returned when either f
aceOnDocumentStatus or textOnDocumentStatus is
“CannotConBrmIDIsAuthentic”. These are images of the
ID with red ellipses around example areas where
tampering was detected.
9. scannedIDPhotoFaceFoundWithMinimumQuality is a
boolean to indicate that a face was found on the ID with
minimum quality.
10. didCompleteIDScanWithoutMatchingOCRTemplate is a
boolean to indicate that the ID Scan was completed
without attempting to match an OCR Template.
11. Note that the ID Scan can visibly look "good enough", but
could reject certain under-the-hood checks. In this case,
the User will likely succeed on a quick Retry when they
provide slightly better additional data.
12. The documentData object is a JSON String that contains
extracted NFC, Barcode, OCR, and User ConBrmed data.
13. The documentData object contains extracted NFC signing
certiBcate data on NFC scans.
14. Check out the v9.4.0 Release Notes for more information
on OCR, Barcode, and NFC capabilities.

POST /match-3d-2d-face-portrait
Processes a high-quality, 1st generation 2D Image against a
previously-processed 3D FaceMap. See 3D:2D Face
Portrait/NFC Matching Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

Notes
1. Match Level 9 (99.99995%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.

POST /match-3d-2d-face-portrait-low-
quality
Processes a low-quality, 1st generation 2D Image against a
previously-processed 3D FaceMap. See 3D:2D Face
Portrait/NFC Matching Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

Notes
1. Match Level 5 (99.99%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.

POST /match-3d-2d-3rdparty-idphoto

Processes a 2D Image of an ID Photo of an unknown source

against a Liveness-proven 3D FaceMap. See 3D:2D 3rd-Party
ID Photo Image Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

Notes
1. Match Level 7 (99.9999%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.

POST /match-3d-2d-3rdparty-idphoto-
low-quality
Same as match3D_2D_3rdparty_idPhoto, but remove
FaceTec's minimum image quality requirements so you can
compare smaller and low-quality images, but with lower
accuracy rates. See 3D:2D 3rd-Party ID Photo Image Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

Notes
1. Match Level 5 (99.99%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify the Match
Level required for success to be true in the response.
minMatchLevel cannot be set to 0. minMatchLevel setting
does not affect underlying Algorithm behavior.

POST /match-3d-2d-proFle-pic
Matches a 3D FaceMap to a social media proBle photo. See
3D:2D ProVle Pic - Matching Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

Notes
1. Match Level 6 (99.999%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.
3. ProBle Pic photos often contain Blters, glamorization, and
other manipulation. FaceTec does not guarantee
resiliency against ANY type of manipulation. The ProBle
Pic algorithm should be used for rough checks and
Bltration ONLY, not for Re-VeriBcation or for Searching.
4. Images of Users wearing sunglasses will not be
processed.

POST /match-3d-2d-kiosk-pos
Match a previously enrolled 3D FaceMaps against a 2D Kiosk
and POS-style images. See 3D:2D Kiosk POS - Matching
Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

POST /match-3d-2d-kiosk-pos-low-
quality
Match a previously enrolled 3D FaceMaps against a 2D Kiosk
and POS-style images, but remove FaceTec's minimum 2D
image quality requirements so you can compare smaller and
low-quality images at a cost of lowered accuracy rates. See
3D:2D Kiosk POS - Matching Guide.

Parameters
image: Base64 Image
externalDatabaseRefID: String (More Information)
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
imageProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was Matched against the 2D Image at
minMatchLevel or greater.

Notes
1. Match Level 5 - 99.99% (1/10,000 FAR) is the maximum
Match Level returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.

POST /liveness-2d
Performs a 2D Liveness Check. See Free Unlimited 2D
Liveness Checks Guide for more info.

Parameters
image: Base64 Image

Response
success: Boolean

Additional Response Properties

liveness2DStatusEnumInt: Liveness Check 2D Status (int)
isLikelyRealPerson: Boolean
liveness2DStatusMessage: String

Success Criteria
success is true if ALL of the following are true:

1. The 2D Image was assessed and it was determined that

the 2D Image was likely a Live Human.

POST /match-2d-2d
Performs a 2D:2D Match. See Free Single-Frame 2D Liveness
Checks Guide.

Parameters
image0: Base64 Image
image1: Base64 Image
minMatchLevel: Match Level

Response
success: Boolean
matchLevel: Match Level
image0ProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW
image1ProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW

Success Criteria
success is true if ALL of the following are true:

1. The 2D Image0 was Matched against the 2D Image1 at

minMatchLevel or greater.

Notes
1. Match Level 6 (99.999%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.
3. Match Level reliability is heavily dependent on the image
quality being used.

POST /match-2d-2d-low-quality
Performs a 2D:2D Match but removes FaceTec's minimum
image quality requirements so you can compare smaller and
low-quality images, but with lower accuracy rates. See Free
Single-Frame 2D Liveness Checks Guide.

Parameters
image0: Base64 Image
image1: Base64 Image
minMatchLevel: Match Level

Response
success: Boolean
image0ProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW
image1ProcessingStatusEnumInt: 0 =
FACE_FOUND_WITH_SUFFICIENT_QUALITY, 1 =
INVALID_IMAGE, 2 = VALID_IMAGE_BUT_DETECTION_ISSUE, 3
= QUALITY_TOO_LOW
matchLevel: Match Level

Success Criteria
success is true if ALL of the following are true:

1. The 2D Image0 was Matched against the 2D Image1 at

minMatchLevel or greater.

Notes
1. Match Level 5 (99.99%) is the maximum Match Level
returned.
2. minMatchLevel allows Developers to specify a Match
Level that they would like to target for success to be true
in the response. minMatchLevel cannot be set to 0.
minMatchLevel setting does not affect underlying
Algorithm behavior.
3. Match Level reliability is heavily dependent on the image
quality being used.

POST /estimate-age-3d-v2
Performs an Age Estimation on a 3D FaceMap. See Age Check
Guide.

Parameters
externalDatabaseRefID: String (More Information)

Response
success: Boolean
ageV2GroupEnumInt: 0 = Age estimate not available, 1 = Age
Under 8, 2 = Age Over 8, 3 = Age Over 13, 4 = Age Over 16, 5 =
Age Over 18, 6 = Age Over 21, 7 = Age Over 25, 8 = Age Over 30

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The Age Estimate was performed and an Age Estimate
Group was returned.

Notes
1. Age Estimation is one of the only APIs where you do not
"key off" success. Success merely tells you the Age
Estimation was run. You need to check the
ageEstimateGroup to query the Age Estimate Group.
2. An ageEstimateGroupV2EnumInt value of 0 will be
returned if age estimation fails to run.

POST /check-age-3d-v2
Performs an Age Check on a 3D FaceMap. See Age Check
Guide.

Parameters
externalDatabaseRefID: String (More Information)
ageCheckTargetEnumInt: 2 = Age Over 8, 3 = Age Over 13, 4 =
Age Over 16, 5 = Age Over 18, 6 = Age Over 21, 7 = Age Over
25, 8 = Age Over 30

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The Age Check was performed and the conBdence is very
high that the subject is within the Age Check Group
targeted.

Notes
1. If the success is false, it doesn't mean the SDK assessed
that the 3D FaceMap IS NOT from the target Age Check
Group. Success being false means that the SDK could not
assess with high enough conBdence that the 3D FaceMap
came from the target Age Check Group. Success being
false could indicate an unusual scan or environmental
conditions, or that only a medium conBdence could be
made.

POST /estimate-age-2d-v2
Performs an Age Estimation on a 2D Image. See Age Check
Guide.

Parameters
image: String

Response
success: Boolean
ageV2GroupEnumInt: 0 = Age estimate not available, 1 = Age
Under 8, 2 = Age Over 8, 3 = Age Over 13, 4 = Age Over 16, 5 =
Age Over 18, 6 = Age Over 21, 7 = Age Over 25, 8 = Age Over 30

Success Criteria
success is true if ALL of the following are true:

1. A 2D image with suucient quality was used.

2. The Age Estimate could be performed and an Age
Estimate Group was returned.

Notes
1. Age Estimation is one of the only APIs where you do not
"key off" success. Success merely tells you the Age
Estimation was run. You need to check the
ageEstimateGroup to query the Age Estimate Group.
2. An ageEstimateGroupV2EnumInt value of 0 will be
returned if age estimation fails to run.
3. ConBdence levels are lower when using 2D Images
instead of 3D FaceMaps, so try to use a 3D FaceMap if
you can. ConBdence degradation is heavily dependent on
the image quality used.

POST /check-age-2d-v2
Performs an Age Check on a 2D Image. See Age Check Guide.

Parameters
image: Base64 Image
ageCheckTargetEnumInt: 2 = Age Over 8, 3 = Age Over 13, 4 =
Age Over 16, 5 = Age Over 18, 6 = Age Over 21, 7 = Age Over
25, 8 = Age Over 30

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. A 2D image with suucient quality was used.

2. The Age Check was performed and the conBdence the
subject is within the Age Check Group targeted is very
high.

Notes
1. If the success is false, it doesn't mean the SDK assessed
that the 2D Image IS NOT from the target Age Check
Group. Success being false means the SDK could not
assess with high enough conBdence that the 2D Image
came from the target Age Check Group. Success being
false could indicate an unusual scan or environmental
conditions, or that only a medium conBdence could be
made.
2. ConBdence levels are lower when using 2D Images
instead of 3D FaceMaps, so try to use a 3D FaceMap if
you can. ConBdence degradation is heavily dependent on
the image quality used.

POST /facemap-audit-data
Gets the AuditTrailImage data of a 3D FaceMap (where
Liveness was Already Proven).

Parameters
faceMap: string

Response
success: Boolean
auditImage: image bytes
createdDateFaceScan: Date (epoch)
processedDateFaceMap: Date (epoch)

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D FaceMap was created using v9.0.0+ of the SDK.
3. Data was successfully retrieved.

Notes
1. Only FaceMaps created using V9 of the FaceTec SDKs are
compatible with this function.

POST /3d-db/enroll
Enrolls a 3D FaceMap retrieved from your External Database
into the 3D-DB. See 1:N Search Guide.

Parameters
externalDatabaseRefID: String (More Information)
groupName: String

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The externalDatabaseRefID was used to retrieve the 3D
FaceMap and the externalDatabaseRefID was not already
in the 3D-DB.
3. The 3D FaceMap was stored in the 3D-DB.

Notes
1. The FaceTec Server uses the externalDatabaseRefID
when specifying an identiBer in the Server Core API.

POST /3d-db/search
Searches the 3D-DB with a 3D FaceMap retrieved from your
External Database. See 1:N Search Guide.

Parameters
externalDatabaseRefID: String (More Information)
groupName: String
minMatchLevel: Match Level

Response
success: Boolean

results: Array of Search Results containing Match Level and

IdentiBers.

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The 3D-DB could be searched.

Notes
1. Note that success is true if the search was performed,
regardless of if there was a match of minMatchLevel or
higher. You must iterate over the search results and
decide how to handle the results.
2. The Search Results will only return the matches that have
a Match Level of minMatchLevel or higher. Matches that
have a lower Match Level will not be returned.
3. minMatchLevel cannot be set to 0.
4. minMatchLevel of 15 is recommended.

POST /3d-db/search-n-n
Performs an N to N Search of the 3D-DB. See 1:N Search
Guide.

Parameters
groupName: String

Response
success: Boolean

A N to N Search Result containing a map of identiBers to a list

of identiBers they matched to.

Success Criteria
success is true if the following is true:

1. The 3D-DB could be searched.

Notes
1. Note that success is true if the search was performed,
whether or not results were returned. You must iterate
over the results and decide how to handle them.
2. N to N search uses a minMatchLevel of 15 as the criteria
for a match.

POST /3d-db/delete
Removes a 3D FaceMap from the 3D-DB search group. See 1:N
Search Guide.

Parameters
identiXer: String
groupName: String

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. The identiBer was removed from the 3D-DB.

POST /3d-db/get
Checks if the 3D FaceMap exists in the 3D-DB. See 1:N Search
Guide.

Parameters
identiXer: String
groupName: String

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. An entry exists in the 3D-DB for the identiBer and

groupName combination.

Additional Search APIs

Search
/3d-one-eye-covered-db/search/
Searches the 3D-DB with a 3D FaceMap where the User has
one of the eyes covered.

/3d-2d-kiosk-pos-db/search
Searches the 3D-DB with a 2D Kiosk and POS-style images.

/3d-2d-face-portrait-db/search
Searches the 3D-DB with high-quality, 1st Generation digital
frontal face images, including images stored in NFC chips or
from a Government database.

Parameters
Image: Base64 Image
groupName: String
minMatchLevel: Match Level

Response
success: Boolean

Array of Search Results containing Match Level and identiBers.

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used or a valid Base64 Image was used (if using a
3D:2D API).
2. The 3D-DB could be searched.

Notes
1. To search your 3D-DB with low-quality 2D Kiosk and POS-
style images use POST/3d-2d-kiosk-pos-db/search-low-
quality API.
2. To search your 3D-DB with low-quality, 1st Generation
digital frontal face images use POST3d-2d-face-portrait-
db/search-low-quality API.

Enroll
Enrolls a 3D FaceMap retrieved from your External Database
into the 3D-DB. See 1:N Search Guide.

/3d-one-eye-covered-db/enroll

/3d-2d-kiosk-pos-db/enroll

/3d-2d-face-portrait-db/enroll

Parameters
externalDatabaseRefID: String (More Information)
groupName: String

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. A 3D FaceMap (where Liveness was already Proven) was

used.
2. The externalDatabaseRefID was used to retrieve the 3D
FaceMap and the externalDatabaseRefID was not already
in the 3D-DB.
3. The 3D FaceMap was stored in the 3D-DB.

Notes
1. The FaceTec Server uses the externalDatabaseRefID
when specifying an identiBer in the Server Core API.

Get
Checks if the 3D FaceMap exists in the 3D-DB. See 1:N Search
Guide.

/3d-one-eye-covered-db/get

/3d-2d-kiosk-pos-db/get

/3d-2d-face-portrait-db/get

Parameters
identiXer: String
groupName: String

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. An entry exists in the 3D-DB for the identiBer and

groupName combination.

Delete
Removes a 3D FaceMap from the 3D-DB search group. See 1:N
Search Guide.

/3d-one-eye-covered-db/delete

/3d-2d-kiosk-pos-db/delete

/3d-2d-face-portrait-db/delete

Parameters
identiXer: String
groupName: String

Response
success: Boolean

Success Criteria
success is true if ALL of the following are true:

1. The identiBer was ensured to be removed from the 3D-DB.

POST /export-3d-facemap
Exports (re-encrypts) a 3D FaceMap using the Public Key
speciBed for exporting in the [Link].

Parameters
IdentiXer: String (More Information)

Response
success: Boolean
exportedFaceMapBase64: Base64 FaceMap

POST /import-3d-facemap
Imports a 3D FaceMap. This API uses the Core import API to
validate and transform the 3D FaceMap into a usable 3D
FaceMap for your application. You must have initialized the
Server SDK with a private key corresponding to the public key
that was used to export the 3D FaceMap you are using.

Parameters
externalDatabaseRefID: String (More Information)
faceMap: Base64 FaceMap

Response
success: Boolean
isFaceMapImported: Boolean

POST /export-for-facetec
Receives a 3D FaceScan, 3D FaceMap, or IDScan and outputs
a new Base64 String that can be copied to FaceTec for
debugging.

Parameters
faceScanOrFaceMapOrIDScan: Base64 3D FaceScan, 3D
FaceMap, or IDScan

Response
success: Boolean
exportedFaceTecDataForDebugBase64: String

POST /convert-facemap-to-face-
vector
Converts a 3D FaceMap in the database to a 3D FaceVector.

Parameters
externalDatabaseRefID: String (More Information)

Response
success: Boolean

Notes
1. If the externalDatabaseRefID is a reference to a stored
FaceVector then this will error. The API will only convert
FaceMaps.

POST /convert-to-universal-face-
vector
Converts a 3D FaceMap in the database to a Universal
FaceVector.

Parameters
externalDatabaseRefID: String (More Information)

Response
success: Boolean

POST /match-3d-3d-face-vector
Matches one 3D FaceVector against the other 3D FaceVector.

Parameters
externalDatabaseRefID: String (More Information)

faceVector: FaceVector

Response
success: Boolean

Search Docs... 

© 2025 FaceTec, Inc. · Multiple US & International Patents Granted · All

Rights Reserved
Terms & Conditions. · Site Privacy Policy. · SDK Privacy Policy. 