# Verify Video

Checks whether a video was generated or signed by Bria, via its C2PA manifest and Bria's invisible watermark.

Endpoint: POST /v2/video/verify

## Request fields (application/json):

  - `video` (string, required)
    A publicly accessible video URL. Accepts MP4, MOV, or M4V.

## Response 200 fields (application/json):

  - `result` (object, required)

  - `result.verified` (boolean, required)
    True if either the C2PA or the invisible-watermark signal confirms Bria origin.

  - `result.c2pa` (object, required)
    The result of checking the media's embedded C2PA manifest against Bria's trust anchor. See the [C2PA specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html) for the manifest structure.

  - `result.c2pa.present` (boolean, required)
    Whether the media carries an embedded C2PA manifest at all.

  - `result.c2pa.is_trusted` (boolean, required)
    Whether the manifest's signing certificate chains up to Bria's own trust anchor. `true` only when `validation_state` is `Trusted`; `false` when `Valid`, `Invalid`, or no manifest is present at all.

  - `result.c2pa.validation_state` (string)
    The manifest's C2PA signature validation outcome; omitted when `present` is `false`. `Invalid` means the signature itself is broken or the media was tampered with after signing. `Valid` means the signature is cryptographically intact but the signer isn't on Bria's trust list — it may be another vendor's legitimate C2PA credential or a self-signed one, so it's not evidence of Bria origin; `is_trusted` is `false` here. `Trusted` means the signing certificate chains all the way up to the exact certificate Bria registered as its own trust anchor — only this case sets `is_trusted` to `true`.
    Enum: "Invalid", "Valid", "Trusted"

  - `result.invisible_watermark_detected` (boolean)
    Bria's invisible-watermark check result. Omitted when the check didn't run at all — for images, this happens for formats the check can't round-trip through (GIF and WEBP); video always runs the check, so this field is always present there. `true`/`false` means the check ran and did or didn't detect the watermark.

  - `request_id` (string, required)
    A unique identifier for this request, echoed back for support/debugging.

## Response 400 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 413 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 415 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 422 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 429 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 460 fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)

## Response 5XX fields (application/json):

  - `error` (object, required)

  - `error.code` (integer, required)
    Example: 400

  - `error.message` (string, required)

  - `error.details` (string, required)

  - `request_id` (string, required)