Request contract
Send a POST request to the selected NeuroVerify server at /detect/image. Include x-api-key and one binary file in the multipart field named file. Let your HTTP library create the multipart content-type boundary.
The API corrects EXIF rotation. It requires a supported image, at least 224 by 224 pixels, no larger than 10 MB, with exactly one face. The GitBook documentation also states that the face endpoint is not intended for document analysis and that results on identity-document artifacts should not be relied upon.
Read the image envelope
The response envelope is unified_face_authenticity_score. It contains unique_trx_id, filename, content_type, status, status_code, billable, risk_score, risk_level, and message. Scored responses may also include ai_threat_signals.
A successful score has status success. Rejected and error outcomes carry null risk fields. Read status before risk_level, and do not translate null into low risk.
- Low risk: lower observed risk, not proof that the image is authentic.
- Medium risk: inconclusive evidence that should be reviewed with other context.
- High risk: a reason to escalate, not a standalone automatic rejection.
- Rejected: no authenticity score was produced.
Handle operational outcomes
HTTP 200 can represent a successful score or a face-policy rejection. Status code 6 means no face was detected and status code 7 means multiple faces were detected. Both documented outcomes are billable and return no score.
Validation failures use HTTP 400 and should be corrected rather than retried unchanged. Server failures use the documented error state. Because each submission creates a new transaction, account for billability before retries or manual resubmission.
Evidence boundary
Limitations
- The image endpoint is face-based and is not documented as a general document-authenticity endpoint or proof that an image is authentic.
Source record
