Synchronous, Asynchronous or Batch: Choosing a Deepfake Detection API Pattern

Should deepfake detection calls be synchronous, asynchronous or webhook-based?

It depends on who is waiting and for how long. A synchronous call holds the connection open until the result returns. It suits a selfie check during onboarding, where Neural Defend reports under 200 ms p95 on eligible image requests under defined test conditions, and the next screen depends on the answer. An asynchronous call returns a job reference straight away and delivers the result later. It suits a 20-minute recorded interview, an insurance claim video or anything whose processing time you cannot bound.

Webhook-based delivery is a variant of asynchronous processing, not a third architecture. The service calls your endpoint when the job finishes instead of your client asking repeatedly. RFC 9110 gives the HTTP vocabulary for this: 202 Accepted means the request was accepted for processing but processing has not completed. Polling is simpler to operate and easier to test. Webhooks reduce wasted requests and latency to the result, but add signing, retries and duplicate handling to your side.

Batch is for volume without a user in the loop: rescanning a year of onboarding selfies after a new attack pattern is reported, or screening an evidence archive before a case review.

Designing the synchronous path for selfies

Keep the synchronous path narrow: one face image, one call, one decision. NeuroVerify's image endpoint (POST /detect/image) accepts JPEG, PNG, BMP, TIFF, WebP or HEIC up to 10 MB with exactly one face, and returns a status, a risk score and band, and a transaction identifier in the response body. Set the client timeout from the onboarding screen's tolerance, not from a library default of 30 or 60 seconds.

Decide in advance what happens when the deadline passes. The safe default is to route the session to manual review or ask for a retake, never to approve. A timeout does not prove the service failed; the request may have completed. Log the request so a late result can still be attached to the case.

Building an asynchronous job around a synchronous API

Many detection APIs, NeuroVerify included, return video results in the same response as the upload. NeuroVerify's video endpoint (POST /detect/video) accepts files up to 1.5 GB, samples 12 frames by default (configurable from 1 to 100) and returns separate video and audio risk fields. For long files, do not make a user's browser hold that connection. Accept the upload into your own storage, create a job record, and let a worker make the API call.

Give the job a small state machine: received, submitted, completed, rejected, failed, expired. Store the job ID, media hash, requested parameters such as max_frames, and the vendor transaction identifier once it exists. Your front end then polls your job endpoint or listens for your own event, which keeps vendor credentials and retry logic on the server.

The worker must avoid duplicate submissions. NeuroVerify's documentation states the API is not idempotent and each attempt can receive a new transaction identifier, so a worker that crashes after the upload but before saving the result should reconcile before resubmitting. Mark the job as submitted before the call, and treat an unknown outcome as a case for review rather than an automatic retry.

Running batch deepfake analysis that can resume

Build batches from a manifest of items, each with a stable ID, a media reference or digest, the requested analysis and the policy context. Process items independently with bounded concurrency so you stay inside rate limits; NeuroVerify signals throttling with HTTP 429 and a Retry-After interval. Record per-item outcomes as they finish, so a restart picks up where it stopped instead of reprocessing everything.

Report batch results in three numbers plus a list: items scored, items rejected (no face, multiple faces, unsupported format), items failed, and the IDs of the flagged media. A rescan that reports only a pass rate hides the rejected files, which are often the ones worth a second look.

• Cap concurrency below your rate limit and honour Retry-After on 429 responses.
• Never resend an item rejected with HTTP 400 unchanged; fix or skip it.
• Keep the model and policy version with the batch so results can be compared with later reruns.

Measuring deadlines before you commit to a pattern

Measure four numbers on real traffic before choosing: upload time from the user's device, processing time at p95, how long the business decision can wait, and how often users abandon the flow. If processing p95 sits well inside the decision window, stay synchronous. If it does not, switch to asynchronous and design the user experience around a pending state.

Hybrids are common. An onboarding flow can check the selfie synchronously while sending the recorded liveness video to an asynchronous job that must finish before the account is activated. The rule is that every path has a defined owner for unknown and late results.

What the processing pattern does not change

The pattern changes delivery, not detection quality. A synchronous call and a batch job send the same media to the same model and get the same signal back. Authentication, object-level authorization, media size limits, retention and audit rules apply equally to all three. Job IDs and batch manifests are new objects that can leak data across tenants if they are guessable, so issue random identifiers and check ownership on every read.

No pattern removes the need for policy. A medium-risk score delivered by webhook is as inconclusive as one delivered in a response body, and it still needs a review owner.

How Neural Defend fits each processing pattern

NeuroVerify's speed makes the synchronous path practical for identity checks: one request runs six signals, including Live Presence Verification and Face Manipulation Detection, and returns one risk score with evidence. The official Python and TypeScript SDKs handle bounded retries for 429, 500 and 503, which simplifies both workers and batch runners. For investigation backlogs, NeuroDetect lets analysts upload authorized media into cases and download structured results for their own tools. Deployment ranges from managed API to private cloud, on-premises and air-gapped, so batch rescans of sensitive archives can run inside your own boundary.