Deepfake Detection SDK Integration: How to Integrate a Deepfake Detection API

How do developers integrate a deepfake detection API?

A working integration has five parts: credentials, upload, response handling, decision routing and records. Get an API key through vendor onboarding and store it in a secret manager. Send media from your server, never from a browser with a long-lived key. Parse the response envelope, check the outcome status, then apply your own policy to the risk band. Finally, store the transaction identifier and the decision your system made.

With NeuroVerify, the image endpoint is POST /detect/image with the API key in the x-api-key header and one file in a multipart field named file. The video endpoint is POST /detect/video. The official TypeScript client reduces the call to an import and one line, which is where Neural Defend's "two lines to integrate" claim comes from. The code below is the documented TypeScript pattern.

import { NeuroVerifyClient } from "@neuraldefend/sdk"
const result = await new NeuroVerifyClient().detectImage("selfie.jpg")

How should engineering teams use deepfake detection SDKs?

Treat the SDK as a transport adapter and a versioned dependency, not as your domain model. Pin the package version, install it only from the registry named in the vendor's documentation, and review release notes before upgrading. For NeuroVerify that means the neuraldefend package for Python, @neuraldefend/sdk for Node.js, and neuraldefend-mcp when an AI agent needs bounded image and video tools.

Put the SDK behind an interface your application owns, for example a checkSelfie function that returns your own result type. Translate vendor fields into stable internal states at that boundary. Thresholds, step-up rules and review queues live on your side of it. When the vendor ships a new field or status, you change one adapter instead of every caller.

Pick the SDK that matches where capture happens. Neural Defend ships mobile SDKs for Android/Kotlin, iOS/Swift and Flutter for capture inside native apps, backend SDKs for Python, TypeScript/Node.js, Go and Java for server-side checks, a REST API for anything else, and an MCP server for AI agents. Mobile capture plus a backend call is the common pattern for onboarding.

Handling statuses, errors and retries without duplicate charges

Every NeuroVerify response carries an outcome status of success, rejected or error. Success means the media was scored. Rejected means the file failed a validation or face-policy condition, such as no face or several faces, and no authenticity score exists. Error means analysis did not complete. Write an explicit branch for each, and never let an unknown or null value fall through to approval.

Retries need the most care. The documented matrix is simple: do not retry HTTP 400, 401 or 403 without fixing the input or credential; retry 429 after the Retry-After interval; retry 500 and 503 with bounded backoff. The official SDKs already do this for selected responses. They deliberately do not retry timeouts or network failures, because the upload may have reached the service and a second attempt creates another billable transaction. RFC 9110 classes POST as a non-idempotent method, and NeuroVerify's API is documented as not idempotent, so reconcile unknown outcomes before resubmitting.

• Success: store risk_level, risk_score and unique_trx_id, then apply your policy.
• Rejected on HTTP 200 (status codes 6 or 7 for no face or multiple faces): ask the user for a better capture; do not treat it as authentic.
• Rejected on HTTP 400: correct the media or request; do not resend it unchanged.
• Error or timeout: withhold the decision, log the request identifier, and decide whether a manual retry is worth a possible duplicate charge.

What should engineers evaluate before integration?

Check six things before you write production code. First, media fit: does the endpoint accept what your capture flow produces? NeuroVerify's image endpoint takes JPEG, PNG, BMP, TIFF, WebP and HEIC up to 10 MB with at least 224 by 224 pixels and exactly one face; video accepts MP4, AVI, MOV, MKV, WMV, FLV, WebM, OGG and OGV up to 1.5 GB. Second, latency at p95 from your own region with real file sizes. Third, the output contract, including how rejections and missing modalities are represented.

Fourth, deployment: whether you need managed cloud, private cloud/VPC, a secure container, on-premises or air-gapped processing. Fifth, data handling: what the vendor retains, for how long, and under which certifications. Neural Defend holds ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II. Sixth, detection quality on your own genuine and attack samples, scored with MCC and specificity rather than accuracy alone. The proof-of-concept guide lays out a test plan for that last step.

How latency shapes where the call sits in your flow

Latency decides whether detection can run inline while the user waits. Neural Defend reports under 200 ms p95 on eligible image requests under defined test conditions, which is fast enough to check a selfie before the onboarding screen advances. Video takes longer because frames are decoded and sampled, 12 by default, so most teams accept the upload, show a progress state, and check the result before the account is activated.

Set a client timeout that reflects the business deadline, not a library default. If the deadline passes, fall back to a defined path such as manual review, rather than silently approving. Measure p95 and p99 from the region where your servers run, because averages hide the slow tail that users actually notice.

Where an SDK integration helps and where it does not

A good integration makes the detection signal reliable, auditable and cheap to maintain. It does not decide whether to onboard a customer. A low-risk result is not proof that the person is genuine, medium is inconclusive, and high risk should trigger review rather than automatic rejection on its own. Policy, document checks and fraud signals still carry part of the decision.

Server-side checks also cannot see what happened before the file reached your backend. If an attacker streams a deepfake through a virtual camera, the media you receive may look like a normal capture. NeuroVerify's Live Presence Verification signal targets that case, but keep device integrity and session controls in your mobile capture layer as well. NeuroVerify does not analyse ID documents, so pair it with your document verification step.

Why developers choose NeuroVerify

NeuroVerify returns six signals from one request: Visual Safety Screening, Live Presence Verification, Face Manipulation Detection, AI Generative Model Analysis, AI Pixel-Level Manipulation and AI Content Compliance. That replaces separate liveness and deepfake calls with a single risk score and signal-level evidence. Teams typically go live in under 24 hours. The model underneath, ARCAS 1B, ranked first of 36 systems on the public VendorBench-100 image benchmark with an MCC of 0.876, against 0.646 for the next vendor; one benchmark author also co-authored the ARCAS paper, and the results are public for anyone to rerun. Start with the developer quickstart, which walks through a first success, rejection and handled failure.