Skip to main content
Neural Defend

Deepfake Detection API for Developers

The NeuroVerify deepfake detection API for developers has a public OpenAPI 3.0.3 contract at version 1.0.0. It defines two POST operations: /detect/image and /detect/video. Both accept a required file as multipart form data and require x-api-key authentication. Production and staging use separate documented server origins. Image and video operations return different named envelopes, and callers must read the embedded status because HTTP 200 can represent either a score or a billable face-policy rejection.

Maintained byNeural Defend
Updated August 7, 2026
Siva Shankar, Co-founder and CTO of Neural Defend.
Siva ShankarCo-founder & CTO
An article-specific diagram for Deepfake Detection API for Developers organizes key sections including operations and servers, response model, contract boundaries.

Operations and servers

POST /detect/image analyzes a single-face still image. POST /detect/video analyzes a video and its audio track when present, returning separate modality fields. Both operations upload a file with multipart form data.

The OpenAPI document lists https://deepscan.neuraldefend.com for production and https://stage.deepscan.neuraldefend.com for staging. Use a credential issued for the selected environment and do not substitute an unverified origin.

  • Image operationId: detectImage.
  • Video operationId: detectVideo.
  • Required multipart field: file.
  • Optional video query parameters: max_frames and sample_rate.

Response model

Image outcomes are wrapped in unified_face_authenticity_score. Video outcomes are wrapped in unified_video_authenticity_score. Authentication, authorization, and rate-limit failures use an API error object with a detail field.

Read status and status_code before using risk data. The scored, rejected, and error states are part of the application contract. A missing or null score is not a low score.

An article-specific topic map for Deepfake Detection API for Developers organizes key sections including response model, contract boundaries, operations and servers.

Contract boundaries

The OpenAPI contract documents wire fields and HTTP behavior. Official SDKs expose normalized language-specific results and intentionally keep their normalized fields as the stable application surface. MCP clients should rely on the MCP structuredContent contract instead of copying the raw API envelope.

Do not infer tenant rate limits, service-level terms, retention, residency, or endpoint scope from the public schema. Confirm account-specific terms through the onboarding and support process.

Evidence boundary

Limitations

  • The public OpenAPI file does not establish tenant-specific entitlement, rate allowances, pricing, retention, residency, or contractual service levels.

Source record

Sources and references

  1. Neural DefendNeuroVerify Detection API OpenAPI contractVerified August 7, 2026.
  2. Neural DefendNeural Defend documentation indexVerified August 7, 2026.

Start with access

Configure API authentication

Keep the API key server-side, bind it to the intended environment, and handle authentication failures without blind retries.

Review authentication