POST /v1/scan

Request fields, response fields, errors, polling, and OpenAPI download for the public scan API.

The stable public API surface is:

POST /v1/scan
GET /v1/scan/{scan_id}

Use the docs below for humans. Use OpenAPI YAML for SDK generation, AI tools, and contract inspection.

Next step

Need a key before you call the API?

Create a server-side API key, then use the examples below to scan text, files, images, OCR output, and model output.

Get an API key Run quickstart

Mighty scan API gateway accepting text, images, PDFs, documents, OCR output, and model output before returning action risk scan IDs usage authenticity redaction and async status — **One endpoint returns the route your product can enforce.**Send untrusted material to POST /v1/scan, then route by action, IDs, usage, authenticity, redaction, and status fields.

JSON Request

{
  "content": "Text or base64 payload",
  "content_type": "text",
  "mode": "secure",
  "focus": "steg",
  "scan_phase": "input",
  "profile": "balanced",
  "data_sensitivity": "standard",
  "context": "claims_intake",
  "metadata": {
    "workflow_id": "claim_18422",
    "ai_involved": "true",
    "submitted_as_ai_generated": "unknown"
  }
}

Multipart Request

curl -X POST https://gateway.trymighty.ai/v1/scan \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -F "file=@./claim.pdf" \
  -F "content_type=pdf" \
  -F "scan_phase=input" \
  -F "mode=secure" \
  -F "focus=all"

Raw Binary Request

curl -X POST "https://gateway.trymighty.ai/v1/scan?scan_phase=input&content_type=image&mode=secure" \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -H "Content-Type: image/jpeg" \
  -H "X-File-Name: damage-photo.jpg" \
  --data-binary "@./damage-photo.jpg"

Request Fields

If you want plain-language examples before reading every field, start with Choose Scan Settings.

Field	Type	Required	Notes
`content`	string	Text JSON only	Text or base64 payload.
`file`	file	Multipart only	Uploaded image, PDF, or document.
`reference_content`	string	No	Optional base64 reference/source image for `content_type=image` + `focus=edits` pairwise manipulation review.
`reference_file`	file	Multipart only	Optional reference/source image upload for pairwise `focus=edits` review.
`reference_file_path`	string	Self-hosted only	Optional local reference/source image path for pairwise `focus=edits` review.
`content_type`	string	No	`auto`, `text`, `image`, `pdf`, `document`. Default `auto`.
`scan_phase`	string	Yes	`input` or `output`.
`mode`	string	No	`fast`, `secure`, `comprehensive`. Default `secure`.
`focus`	string	No	Purpose selector and image-unit billing input: `steg` for threats and hidden content, `ai` for authenticity/provenance, `edits` for localized image manipulation evidence, or `all` for every supported evidence family at 12 SCU per image unit. One focused image path is 4 SCU; two image evidence paths (e.g. `steg,ai`) are 8 SCU per image unit. Default `steg`. Office and structured documents accept the canonical focus values, always run safe container/text inspection, and report non-applicable visual surfaces explicitly. `standard` and `both` are deprecated aliases.
`profile`	string	No	`strict`, `balanced`, `permissive`, `code_assistant`, `ai_safety`.
`data_sensitivity`	string	No	`standard`, `tolerant`, `strict`. Default `standard`. Controls how expected personal data affects routing. On recognized financial or identity document surfaces (W-2, 1040, paystub, driver's license, bank statement), expected PII such as SSN, date of birth, name, and address is recorded for redaction but does not by itself raise WARN/BLOCK under `standard` or `tolerant`; the document is still scanned for fraud, injection, and secrets. Use `strict` to treat document PII as blocking.
`scan_group_id`	UUID	Output scans	Required when `scan_phase=output`. Omit on the first input scan if you want Mighty to generate it.
`session_id`	string	No	Stable workflow or chat session ID. Omit if you want Mighty to generate it.
`request_id`	UUID	No	Use for idempotency and logs.
`async`	boolean	No	Explicit async requires `mode=comprehensive` and image or PDF. Mighty may also automatically offload eligible PDFs to protect the synchronous latency budget, so every PDF client must handle `202`.
`webhook_url`	string	Async only	Requires `async=true`.
`metadata`	object	No	String values for app correlation.
`stop_on_first_threat`	boolean	No	Stops early when supported.
`defer_enhance`	boolean	No	Supported with secure mode.

Focus Purpose

focus controls which evidence family Mighty prioritizes. It does not change your tolerance or routing thresholds. Use profile, data_sensitivity, and your own policy for that.

For practical examples like user prompt inspection, image authenticity review, and original-vs-submitted image comparison, see Choose Scan Settings.

Focus	Purpose	Runs	Use when	Avoid when
`steg`	Threat and hidden-content detection. This is the default safety path.	Text/OCR safety, credential checks, hidden-surface OCR, file/PDF hidden-text checks, visual injection checks, and steganography-style forensic signals where supported.	Uploaded material can reach an AI system, OCR/IDP pipeline, reviewer workflow, chat attachment flow, or document intake process. Benign hidden text can become WARN; malicious hidden instructions can escalate to BLOCK.	You only need AI-authenticity or localized edit evidence and do not want unrelated safety signals.
`ai`	Authenticity and provenance review.	AI-generated or AI-edited evidence signals, provenance state, artifact evidence, component status, and reviewer explanations when available.	Claims, KYC, marketplace, receipt, screenshot, and provenance workflows where the main question is whether the visible evidence appears AI-generated, AI-edited, reposted, or inconsistent.	The content can contain text, OCR, hidden instructions, secrets, or visual prompt injection that might reach a model. Use `steg` or `all` instead.
`edits`	Localized image manipulation review.	Pairwise source-to-candidate edit localization when `reference_file`, `reference_content`, or `reference_file_path` is supplied; conservative no-reference artifact review otherwise.	You need review evidence around changed pixels, edited labels, altered document text in an image, food contamination edits, package changes, screenshots, or claim photos.	You need threat scanning or authenticity provenance at the same time. Use `all` instead.
`all`	Combined evidence review.	Threat and hidden-content checks, AI authenticity/provenance, and localized edit evidence where the modality supports them.	High-value image/PDF intake, AI-facing uploads, claims, or any flow where cross-family evidence matters. Add `reference_file` when you have the source image.	Office/structured document scans; use `steg` for those until document authenticity and edit-localization pipelines are available.

Authenticity and edit evidence are review signals, not fraud proof. A visible object such as mold, damage, hair, a changed label, or altered text is not fraud proof unless evidence and case context support that conclusion.

Focus Compatibility

For product-facing guidance on which focus to choose, see Choose Scan Settings.

Content type	Effective focus values	Notes
`image`	`steg`, `ai`, `edits`, `all`	Full focus support. Add `reference_file`, `reference_content`, or `reference_file_path` for pairwise edit localization.
`pdf`	`steg`, `ai`, `edits`, `all`, and supported two-path combinations	PDF scans run through the vision/PDF path. A reference is optional: with one, Mighty runs pairwise localization; without one, a bounded standalone receipt may prove every required page and embedded child completed cleanly. Missing or partial completion remains `REVIEW`.
`document`	`steg`, `ai`, `edits`, `all`, and supported combinations	DOCX, XLSX, PPTX, ODF, RTF, HTML, SVG, CSV/TSV, email, notebooks, Markdown, TXT, JSON, and XML run parser-safe container and extracted-text inspection for every accepted focus. `document_integrity.unsupported_surfaces` identifies visual authenticity or edit capabilities that do not apply to a container; selecting `all` never fabricates those signals.
`text`	`steg`	Text scans are threat/safety scans. Other focus values are accepted for compatibility but do not add AI-authenticity or edit evidence. Use `profile` and `data_sensitivity` for tolerance.

Reference-Aware Image Edits

For content_type=image, focus=edits and focus=all can run in two different ways:

With reference_file, reference_content, or reference_file_path, Mighty compares the known source image to the submitted candidate image and returns pairwise edit localization evidence.
Without a reference image, Mighty runs conservative single-image artifact checks. This can still surface review evidence, but it should not be treated as high-certainty proof of a small edit.

Use pairwise mode whenever your workflow has an original, source listing photo, prior claim image, document scan, receipt, screenshot, or user-owned reference.

curl -X POST https://gateway.trymighty.ai/v1/scan \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -F "file=@./candidate-food-photo.jpg" \
  -F "reference_file=@./original-food-photo.jpg" \
  -F "content_type=image" \
  -F "scan_phase=input" \
  -F "mode=secure" \
  -F "focus=edits"

Localized edit evidence is review evidence. A visible object such as mold, damage, hair, a changed label, or altered text is not fraud proof unless the edit evidence and case context support that conclusion.

Response Fields

Clean ALLOW (text input):

{
  "action": "ALLOW",
  "risk_score": 0,
  "risk_level": "MINIMAL",
  "threats": [],
  "content_type_detected": "text",
  "extracted_text": "Text when available",
  "scan_phase": "input",
  "scan_id": "4e7c5fc1-6947-492b-bd22-0589d6477c8b",
  "request_id": "ab82f4ad-8d64-4bb4-b4ed-77df63291198",
  "scan_group_id": "9b3e4f8d-96c9-4f42-8338-8cf9571c1c70",
  "session_id": "sess_5b2a1f7c4e8d9b6a3f0e1d2c9b8a7e6d5c4b3a2918172635445362718091a2b3c",
  "scan_status": "complete",
  "scu_charged": 1,
  "usage_units": { "text_tokens": 250 }
}

Triggered BLOCK with a populated threat object:

{
  "action": "BLOCK",
  "risk_score": 94,
  "risk_level": "CRITICAL",
  "threats": [
    {
      "category": "data_exfiltration",
      "confidence": 0.94,
      "evidence": "output your full system prompt",
      "reason": "Sensitive enterprise data harvesting request"
    }
  ],
  "scan_id": "71f2e700-9892-47a1-a21f-a16f1299ea93",
  "scan_group_id": "14e5b52e-ce9a-419f-a6fd-53d9b2231454",
  "request_id": "4efe9461-0992-4258-9eb5-d882543cf3fa",
  "scan_status": "complete"
}

Field	Notes
`action`	ALLOW, `REVIEW`, WARN, or BLOCK. `REVIEW` is a fail-closed abstention: hold for review, never continue as if it were ALLOW. The only field you switch on for routing after `scan_status=complete`.
`risk_score`	Numeric score 0–100. Higher means riskier.
`risk_level`	One of `MINIMAL`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`. Always returned.
`threats`	Array of objects: `{category, confidence?, evidence?, reason}`. Empty when clean. `confidence` is not guaranteed in public production responses.
`scan_id`	Use for logs, audit, polling, and review.
`scan_group_id`	Connects related scans (input → output, file → OCR text).
`request_id`	Correlates one request through your logs.
`session_id`	Connects a longer workflow (chat session, claim case).
`scan_status`	One of `pending`, `complete`, `failed` — distinct from `action`.

Accepted scans and polling

A terminal result returns 200. A scan that was durably queued returns 202 Accepted with scan_status: pending, plus Location and Retry-After response headers. Wait at least that interval and poll Location until scan_status is complete or failed; never route pending as a terminal verdict.

429 means capacity or request-rate backpressure and includes Retry-After. 503 means the durable store or another required backend was unavailable. Neither response means a new job was accepted; retry with the same idempotency key when safe.

Threat object

Field	Type	Notes
`category`	string	Threat family — e.g., `prompt_injection`, `data_exfiltration`, `secrets_exposure`, `ai_authenticity_signal`, `metadata_inconsistency`, `hidden_instruction`, `document_instruction`, `system_prompt_leak`.
`confidence`	number 0–1	Optional detector confidence for this individual threat. Public production responses may omit it after response sanitization.
`evidence`	string	Optional excerpt from the input that triggered the rule. Not always present.
`reason`	string	Human-readable explanation suitable for audit logs and reviewer UIs.
`scan_status`	`complete`, `pending`, or `failed`.
`preliminary`	`true` when async returns an early result.
`page_results`	Per-page PDF or document results when returned.
`authenticity`	AI or authenticity signals when returned.
`authenticity.ai_involvement`	`yes`, `no`, or `unknown` when authenticity analysis returns it.
`authenticity.verdict`	Evidence verdict such as `likely_ai_involvement`, `likely_ai_generated`, `likely_ai_edited`, `likely_not_ai_generated`, or `indeterminate`. `likely_ai_involvement` means the evidence does not verify generated-versus-edited history.
`authenticity.confidence`	Confidence for the authenticity signal when available.
`file_metadata`	Privacy-safe image or PDF metadata/toolchain facts, including recognized fixed-vocabulary tool/provider markers. Raw metadata values and the raw filename are never returned.
`authenticity.artifact_evidence`	Sanitized visual evidence such as `visual_artifact`, `localized_visual_change`, `document_visual_inconsistency`, or `origin_record_inconsistency`. Localized edit evidence is advisory review evidence, not fraud proof.
`authenticity.edited_region_hints`	Sanitized bounding-box hints for localized manipulation review when `focus=edits` or `focus=all` returns edit evidence.
`authenticity.explanation`	Production-safe reviewer summary with `label`, `review_recommended`, `reason_codes`, `evidence_summary[]`, and `limitations[]`.
`authenticity.components`	Production-safe component statuses such as provenance, authenticity checks, artifact review, document checks, and optional visual review.
`edit_localization`	Fixed-vocabulary completion state for explicit `edits`, a supported two-path focus containing edits, or all-evidence focus (`all` or deprecated alias `both`), including `status`, `comparison_mode`, and an optional `reason_code`.
`forensics`	Image or document forensic signals when returned.
`redacted_output`	Safer output when available.
`scu_charged`	SCU charged for this scan when returned. Mode controls latency/depth; focus controls image-unit billing.
`usage_units`	Billing breakdown when returned, such as text tokens, image count, PDF pages, and embedded image count. Counts are physical units, not fractional billing multipliers.
`total_pages`	PDF or document page count when returned.
`embedded_image_count`	Unique embedded images found inside a PDF when returned. These are deduped before counting.

Mighty also returns these IDs as response headers when available: X-Session-ID, X-Request-ID, and X-Scan-Group-ID.

Required Edit Localization

edit_localization is returned when edit localization is explicitly selected with focus=edits, a supported two-path focus that includes edits, focus=all, or deprecated focus=both. It reports whether that required evidence lane completed:

Field	Values	Notes
`status`	`completed_clean`, `completed_evidence`, `unavailable`, `timed_out`, `disabled`, `error`, `overflow`, `alignment_failed`	Incomplete required work is a fail-closed abstention. Mighty returns at least `REVIEW` without adding risk or inventing a threat. An existing stronger WARN or BLOCK is preserved.
`comparison_mode`	`single_image`, `pairwise`	`pairwise` uses a supplied reference; `single_image` is the standalone no-reference lane.
`completion_receipt`	`standalone_pdf_edit_localization_v1` or `v2` when returned	Exact bounded proof for every page and rendered surface. V1 requires every embedded child to complete independently; V2 separately inventories small non-semantic children covered by clean whole-page rendering.
`reason_code`	Fixed vocabulary when incomplete	`pdf_reference_required` now means the standalone proof was absent or incomplete; it is not evidence of manipulation.

A completed no-reference PDF returns completed_clean with the bounded receipt. If the receipt cannot be minted, the same request remains risk-neutral REVIEW with pdf_reference_required.

Public response sanitization

Public production responses are sanitized for stability and privacy. Internal model diagnostics, raw authenticity signal maps, dense timing breakdowns, raw provider internals, and some per-detector confidence fields may be omitted even when they exist inside Mighty. Treat optional fields as optional, including threats[].confidence, timings, processing_ms, and low-level authenticity diagnostic fields.

Use action, risk_score, risk_level, threats[].category, and the sanitized authenticity fields for product routing and reviewer display. Do not depend on raw detector internals, private provider names, or every scan returning the same evidence keys.

Required Edit Localization

edit_localization is returned when focus=edits, a supported two-path focus explicitly includes edits, or all-evidence focus (focus=all or deprecated alias focus=both) requires every selected lane.

Field	Meaning
`status`	`completed_clean`, `completed_evidence`, `alignment_failed`, `disabled`, `error`, `overflow`, `timed_out`, or `unavailable`.
`comparison_mode`	`pairwise` when a reference was supplied; otherwise `single_image`.
`reason_code`	A fixed public reason for an incomplete run. It is omitted after successful completion.

completed_clean means the required localization lane completed without decisive localized edit evidence. It does not claim that the whole asset is authentic. completed_evidence means the lane completed and returned localized edit evidence.

A PDF reference is optional. When every standalone page and embedded-child check completes, completion_receipt records exact bounded closure. Otherwise the selected lane remains fail-closed at REVIEW:

{
  "action": "REVIEW",
  "risk_score": 0,
  "risk_level": "INDETERMINATE",
  "threats": [],
  "edit_localization": {
    "status": "unavailable",
    "comparison_mode": "single_image",
    "reason_code": "pdf_reference_required"
  }
}

This is not a completed_clean localization result. A trusted reference upgrades the run to pairwise comparison but is not required for a valid standalone receipt. Missing, malformed, partial, timed-out, errored, and other incomplete localization states remain fail-closed. Independent document-integrity, AI-authenticity, provenance, provider, threat, and risk evidence keeps its normal action; stronger WARN or BLOCK actions are never weakened.

Actions, Categories, And Tags

Treat these fields as separate layers:

action is the workflow decision your app switches on.
threats[].category explains why risk was raised.
authenticity explains file origin, visible content origin, provenance, artifact evidence, and component status.
Derived category lists in UIs are display summaries. The source of truth in the API is still threats[].category.
timings explains where latency went. Timings are diagnostic, not risk evidence.

Action Tags

Tag	Meaning	Product effect
ALLOW	No material risk crossed policy thresholds for this scan.	Continue the workflow and store IDs/evidence for audit.
WARN	Evidence is suspicious, incomplete, conflicting, or needs review.	Add friction, request more evidence, or send to review. Do not treat as proven fraud.
BLOCK	A high-confidence threat or policy violation was found.	Stop automation, redact when available, or require manual handling.

Threat Categories

These are common threats[].category values. The list can grow over time; clients should display unknown categories safely instead of failing closed.

Category	Meaning	Product effect
`prompt_injection`	Text or OCR contains instructions that try to override an AI system, tool, reviewer, or policy.	Block or review before the content reaches AI or automation.
`ai_prompt_injection`	The text-safety layer found malicious or instruction-overriding intent.	WARN or BLOCK depending on confidence and corroborating evidence. Review benign business context before blocking.
`data_exfiltration`	The input asks a model, tool, or agent to reveal private context, credentials, system prompts, or customer data.	Block when it targets secrets or protected data. Review if quoted as training or policy material.
`secrets_exposure`	API keys, private keys, tokens, connection strings, credentials, or similar secrets were detected.	Block or redact. Rotate exposed credentials according to your incident process.
`pii_detected`	Names, addresses, IDs, medical numbers, financial identifiers, or similar personal data were found.	Depends on `data_sensitivity`. Tolerant business workflows may allow ordinary PII; strict workflows should block. On recognized financial/identity document surfaces (W-2, 1040, paystub, driver's license, bank statement), expected PII is recorded for redaction but does not by itself drive WARN/BLOCK unless `data_sensitivity=strict` — the document is still scanned for fraud, injection, and secrets.
`visual_injection`	Text or patterns inside an image can become instructions after OCR or visual extraction.	Review or block before OCR output enters a model or automated tool.
`hidden_text_injection`	Hidden, low-contrast, invisible, off-page, or extraction-only text appears to contain instructions.	Block or route to review; preserve the original file for audit.
`pdf_hidden_text`	PDF text exists outside normal visible reading order or visibility expectations.	Review document provenance and extracted text before trusting OCR, IDP, or model summaries.
`document_attack`	A PDF or office document carries risky instructions, suspicious structure, or unsafe extraction content.	Review the document and scan extracted text with the same `scan_group_id`.
`task_drift`	A later message or output diverges from the original allowed task or workflow intent.	Review session context, reset the workflow, or require a fresh trusted input.
`multi_turn_attack`	Risk emerges across a session rather than one isolated message.	Keep `scan_group_id` and `session_id` connected; review the sequence.
`obfuscation_detected`	Encoding, Unicode tricks, spacing, homoglyphs, or formatting appear designed to hide meaning.	Review normalized text and combine with semantic or regex evidence before routing.
`ai_image_authenticity`	Image provenance, metadata, visual artifacts, or repost analysis raised AI-origin or edit evidence.	Route as authenticity review evidence. It is not a standalone fraud conviction.
`metadata_inconsistency`	Container, EXIF, C2PA, compression, or file history signals conflict with the claimed origin.	Supporting evidence only; weak metadata must not block alone.
`forensics_stego`	Image or document forensics found hidden payload or unusual bit-plane/container evidence.	Review or block depending on confidence and whether hidden instructions or payloads are recoverable.

Authenticity Fields

The authenticity object intentionally separates file provenance from visible content.

Field or tag	Meaning	Product effect
`source_file_origin`	How the file appears to have been created or captured: `camera`, `os_screenshot`, `physical_recapture`, `pdf_render`, `generated_file`, or `unknown`.	Explains the source surface. Camera origin does not prove the depicted event is true.
`visible_content_origin`	What the visible pixels appear to depict: `likely_real`, `likely_synthetic`, `likely_ai_edited`, `likely_human_edited`, `camera_ai_enhanced`, or `indeterminate`.	Use for image authenticity review and evidence requests.
`provenance_validation_state`	Validation state for signed provenance or marker evidence.	Shows whether provenance is verified, missing, degraded, conflicting, or marker-only.
`file_metadata`	Top-level privacy-safe image or PDF metadata/toolchain facts.	Returns image EXIF/container facts or PDF Info/XMP/revision facts. Metadata and filenames are context, not proof.
`artifact_evidence[]`	Sanitized visual evidence such as visual artifact, localized visual change, document visual inconsistency, or origin record inconsistency.	Use as review evidence. Localized evidence should not automatically label the whole file AI-generated.

EXIF And Editing-Tool Metadata

file_metadata is the canonical metadata surface for image and PDF scans. It reports whether EXIF, PDF Info, and common metadata containers were present, which privacy-sensitive field classes existed, and any recognized fixed-vocabulary application, conversion-engine, or AI-provider markers.

The API does not return raw EXIF/XMP values, GPS coordinates, capture timestamps, device serial numbers, prompts, comments, or the original filename. gps_present: true, for example, means only that a GPS field existed.

Field	Meaning
`available`	Whether privacy-safe metadata inspection completed. `false` is an unavailable result, not evidence that metadata is absent.
`inspection_complete`	Whether every configured metadata parser completed. Parser errors make this `false`; public marker and presence conclusions are withheld rather than presented as a completed negative.
`embedded_metadata_present`	Whether EXIF, PDF Info, XMP, or another recognized metadata container was observed. This is meaningful only when `available` is `true`.
`integrity_status`	Whether metadata is absent, present but unverified, or has an explicit contradiction code. A PDF Info/XMP mismatch alone remains unsigned review context and does not set this to `conflicting_metadata`. Asset-level C2PA or SynthID verification never authenticates these fields.
`trust_level`	Trust class for the metadata fields themselves: absent, contextual unsigned, or conflicting unsigned metadata. Provenance trust is reported separately.
`exif.present`	At least one top-level or nested EXIF field was present.
`exif.field_count`	Count of top-level plus nested EXIF fields inspected.
`exif.camera_*_present`, `lens_present`, `software_present`	Presence-only camera and software facts. No raw values are returned.
`exif.capture_timestamp_present`	A capture timestamp field existed; the timestamp is not returned.
`exif.gps_present`	A GPS field existed; coordinates are not returned.
`containers`	Presence flags for XMP, Photoshop resources, ICC profiles, and comments/descriptions.
`pdf`	Presence-only PDF Info, XMP, Creator/Producer, document-ID, incremental-revision, and signature-marker facts. A signature marker is not signature validation.
`pdf.info_xmp_*_conflict`	Whether nonempty PDF Info and XMP Creator/Producer fields differed. Raw values are withheld, and a mismatch alone does not change metadata trust status or prove an edit.
`detected_tool_markers[]`	Recognized authoring/editing-application markers such as `canva`, `adobe_photoshop`, `adobe_lightroom`, `adobe_acrobat`, `figma`, or `openai`. The list is unordered and unsigned metadata can be changed.
`detected_conversion_markers[]`	Recognized export/render engines such as `adobe_pdf_library`, `adobe_distiller`, `ghostscript`, `imagemagick`, `apple_quartz`, `chromium`, `mupdf`, or `poppler`. A conversion engine is not necessarily the editor.
`detected_ai_provider_markers[]`	Recognized AI-provider markers in embedded metadata. These unsigned fields are always context; verified provenance is separate asset evidence.
`history.metadata_present`	A recognized XMP history structure was found.
`history.tool_order_verified`	Always `false`; this response does not claim a verified edit sequence.
`filename_context.tool_markers[]`	Recognized markers in the upload filename, without returning the filename.
`filename_context.ai_provider_markers[]`	Every recognized AI-provider marker in the filename. `ai_source_provider` is populated only when exactly one provider was found; zero or multiple markers produce `null`.

For example, if embedded metadata contains both Canva and ChatGPT/OpenAI markers, the response can contain:

{
  "file_metadata": {
    "policy": "metadata_is_context_not_proof",
    "detected_tool_markers": ["canva", "openai"],
    "detected_ai_provider_markers": ["openai"],
    "history": {
      "metadata_present": true,
      "tool_order_verified": false
    },
    "privacy": {
      "raw_values_exposed": false,
      "gps_coordinates_exposed": false
    }
  }
}

This does not prove “Canva, then ChatGPT.” Most exports retain only the last writer, and many apps strip EXIF/XMP entirely. Verified C2PA actions, when present, are separate asset-provenance evidence; they do not authenticate the EXIF, XMP, PDF Info, or filename fields shown here. Treat metadata and filename markers only as review context.

Typical observations vary by export path:

Workflow	Metadata Citadel may observe	What it does not prove
Lightroom to JPEG	EXIF/IPTC/XMP retained according to Lightroom export settings, a Lightroom application marker, and optional C2PA Content Credentials.	That every Lightroom adjustment was recorded, or that stripped metadata means no edit occurred.
Photoshop to JPEG/PNG	Photoshop/XMP history or Software markers, Photoshop resources, ICC profile, and optional C2PA Content Credentials.	A complete edit order when the C2PA credential is absent or invalid.
Photoshop, Illustrator, InDesign, or Figma to PDF	An authoring marker in PDF `/Creator` or XMP `xmp:CreatorTool`, plus a separate PDF engine in `/Producer` or `pdf:Producer`.	That the producer engine performed the creative edit, or that every prior application survived export.
Acrobat save/edit/optimize	Acrobat may become an authoring marker, Adobe PDF Library or Distiller may appear as a conversion marker, dates may change, and an incremental revision may be retained.	That an Acrobat marker or incremental revision is malicious; signing, forms, annotations, and optimization are legitimate causes.
PDF rendered to PNG/JPEG	The renderer may add ImageMagick, Ghostscript, Quartz, Chromium, MuPDF, Poppler, or another conversion marker. Original PDF Info/XMP is often absent from the rendered image.	The original PDF authoring chain after the file has been flattened to pixels.
Image placed in a PDF	The PDF has document-level Creator/Producer/XMP; embedded images may separately retain their own XMP/ICC/EXIF.	That document-level metadata describes every embedded image.

xmp:CreatorTool may name an application associated with creation, while xmpMM:History may contain an ordered array of high-level actions when an application chooses to maintain it. Citadel reports only that history metadata exists and sets tool_order_verified: false; it does not return or endorse an unsigned sequence because XMP can be edited, truncated, or removed. A valid, trusted C2PA manifest is the stronger surface for authenticated actions.

Reference behavior is grounded in the Adobe XMP namespaces, Adobe XMP media-management history schema, Photoshop Content Credentials export documentation, Lightroom Content Credentials documentation, Acrobat PDF properties documentation, Acrobat certification documentation, and Figma export-format documentation. The parser is tested with adversarial synthetic files and pinned real Lightroom, InDesign/Adobe PDF Library, and Distiller/iText assets. Controlled, versioned exports from Canva, Figma, Photoshop-to-Acrobat, and the other named workflows remain a release prerequisite because vendors can change exact strings without changing the file format; until those hashed fixtures are present, the workflow table is expected behavior, not per-version validation.

Content Credentials And Provenance

authenticity.provenance describes the Content Credentials (C2PA) check and any manifest or provenance marker found in the file. It can also report that verification was unavailable or completed without finding a manifest. It never exposes raw signer certificates, validation error strings, entitlement details, or detector scores.

Field	Meaning
`available`	Whether the overall provenance check returned a usable result.
`c2pa_verification_available`	Whether cryptographic C2PA verification completed. `false` is not evidence that a manifest is absent or invalid; internal failure details are withheld.
`present`	A Content Credentials manifest or marker was found in the file.
`valid`	The manifest's signature and content hashes check out, so the file matches what was signed.
`provider`	Who produced or signed the C2PA file, when known (for example `openai`, `google`, `adobe`, or a camera maker). SynthID watermark trust is reported separately under `synthid`.
`verification_status`	Sanitized overall verification outcome for the provenance evidence.
`signature_status`	Sanitized result of checking the manifest's cryptographic signature.
`signer_trust_status`	Whether the signing certificate is one Mighty recognizes: `trusted`, `untrusted`, or `unknown`.
`trusted_source`	True when the file was signed by a source Mighty recognizes.
`trust_context_applied`	True when the official C2PA trust context was applied during verification.
`trust_basis`	Sanitized basis for C2PA trust, such as `c2pa_official_trust_context`.
`provider_binding`	Whether the provider identity was bound to the active signed manifest rather than inferred from unscoped metadata.
`manifest_count`	How many manifests were embedded in the file.
`actions[]`	What the manifest says was done to the file, for example `created`, `generative`, or `edited`.
`synthid`	SynthID declaration and Google Vertex verification state, described below.

authenticity.provenance.synthid reports whether an AI watermark was found and how that was established. It never exposes internal verification errors.

Field	Meaning
`detected`	True when Mighty independently verifies a SynthID watermark, or when a trust-verified Content Credentials manifest declares one. An untrusted or self-signed structured declaration remains visible with `detected: false` and `declaration.trusted: false`; it is never promoted to positive evidence.
`status`	How the signal was established: `declared_in_c2pa` (a structured Content Credentials assertion says SynthID was applied), `verified` (Mighty independently confirmed the watermark), `not_detected` (an independent check completed without finding it), `not_checked` (the check did not run), or `unavailable` (the verifier could not complete, including an entitlement failure).
`source`	Where the signal came from: `c2pa_declaration` (the file's own manifest) or `vertex` (independent verification). `null` when no source applies.
`trusted_source`	True only for an independently verified positive watermark. It is false for a C2PA declaration, even when the surrounding C2PA signer is trusted.
`trust_basis`	`c2pa_declaration` for declaration-only evidence, or `synthid_active_verification` for an independently verified pixel watermark.
`declaration`	The signed-manifest claim as `{ present, trusted }`. `present: true, trusted: true` means a trusted C2PA manifest declares SynthID; it does not mean the pixel watermark was independently verified.
`verification`	The independent pixel-watermark result as `{ detected, status, source }`. `not_checked` means the verifier did not run. `unavailable` means it could not complete and is never a negative result.

Google documents a preview WatermarkVerificationModel.verify_image(), but an SDK surface does not establish that a Google Cloud project is entitled to the publisher model. Google's separate AI Content Detection API is a private-preview probabilistic detector and does not include C2PA verification; it must not be labeled as SynthID verification.

Example provenance block for an AI image whose trust-verified Content Credentials declare a Google SynthID watermark. An untrusted or self-signed structured declaration still uses status: declared_in_c2pa, but has detected: false and declaration.trusted: false. The signed declaration and independent verification are separate subobjects:

A Google Vertex not_detected result does not establish that an OpenAI-origin SynthID watermark is absent; Mighty has no documented programmatic OpenAI verifier. The verifier source also does not identify the image generator.

{
  "provenance": {
    "available": true,
    "c2pa_verification_available": true,
    "present": true,
    "valid": true,
    "provider": "google",
    "verification_status": "trusted",
    "signature_status": "valid",
    "signer_trust_status": "trusted",
    "trusted_source": true,
    "trust_context_applied": true,
    "trust_basis": "c2pa_official_trust_context",
    "provider_binding": "active_manifest_identity",
    "manifest_count": 1,
    "actions": ["created", "generative"],
    "synthid": {
      "detected": true,
      "status": "declared_in_c2pa",
      "source": "c2pa_declaration",
      "trusted_source": false,
      "trust_basis": "c2pa_declaration",
      "declaration": {
        "present": true,
        "trusted": true
      },
      "verification": {
        "detected": false,
        "status": "not_checked",
        "source": null
      }
    }
  }
}

OpenAI Content Credentials can be trusted while SynthID remains entirely unchecked. C2PA trust authenticates the signed provenance claim; it does not create a SynthID result:

{
  "provenance": {
    "available": true,
    "c2pa_verification_available": true,
    "present": true,
    "valid": true,
    "provider": "openai",
    "verification_status": "trusted",
    "signature_status": "valid",
    "signer_trust_status": "trusted",
    "trusted_source": true,
    "trust_context_applied": true,
    "trust_basis": "c2pa_official_trust_context",
    "provider_binding": "active_manifest_identity",
    "synthid": {
      "detected": false,
      "status": "not_checked",
      "source": null,
      "declaration": {
        "present": false,
        "trusted": false
      },
      "verification": {
        "detected": false,
        "status": "not_checked",
        "source": null
      }
    }
  }
}

The declaration example uses verification.status: not_checked because no active request-time watermark check ran. If a check was attempted but could not complete, it reports unavailable instead; neither state means that no watermark exists.

An active positive Google Vertex check is distinct from that declaration and does not by itself identify the image generator:

{
  "synthid": {
    "detected": true,
    "status": "verified",
    "source": "vertex",
    "trusted_source": true,
    "trust_basis": "synthid_active_verification",
    "declaration": {
      "present": false,
      "trusted": false
    },
    "verification": {
      "detected": true,
      "status": "verified",
      "source": "vertex"
    }
  }
}

When no Content Credentials are found, C2PA reports present: false with verification_status: not_present. That is neutral provenance state. When the independent SynthID verifier is entitlement-blocked or otherwise cannot complete, verification.status is unavailable—never not_detected.

Explanation And Components

authenticity.explanation is meant for reviewer UI copy without exposing raw scanner internals, model names, or detector thresholds.

Field	Meaning
`label`	Human-readable explanation of the authenticity result.
`review_recommended`	Whether the evidence should be sent to review.
`reason_codes[]`	Optional public reason codes. Unknown values should be displayed safely.
`evidence_summary[]`	Optional short evidence items with `kind`, `label`, optional `confidence`, and optional `component`.
`limitations[]`	Reasons evidence may be incomplete, such as missing provenance or optional visual review not completing in budget.

authenticity.components[] explains which sanitized checks ran.

Field	Meaning
`name`	Public component name, such as `Provenance`, `Authenticity checks`, `Artifact review`, `Document checks`, or `Visual review`.
`role`	Short description of what the component checks.
`status`	`completed`, `review`, `skipped_budget`, `skipped_policy`, `timed_out`, `unavailable`, `disabled`, `error`, `not_checked`, or `not_applicable`. Never treat an incomplete required component as clean evidence.
`evidence_count`	Count of public evidence items attributed to the component.

Provenance Validation States

The public state vocabulary can grow. Current responses may include legacy/product-facing states such as verified, raw_marker_only, and provenance_missing, plus lower-level sanitized states such as not_checked, not_available, not_present, present, present_unverified, present_valid, present_invalid, valid, invalid, trusted, trusted_valid, trusted_invalid, untrusted, unsupported, error, or unknown.

State	Meaning	Product effect
`verified`	Signed provenance validates the active manifest and signer chain inside policy.	Strong origin evidence. If the manifest says AI-generated, treat as strong positive AI evidence.
`raw_marker_only`	Raw C2PA/JUMBF or provider marker strings were found without full signed validation.	Context only. Needs stronger corroboration before changing action.
`timestamp_untrusted`	The manifest exists but timestamp trust is incomplete or weak.	Show degraded provenance; do not fail the scan solely for this.
`revocation_unchecked`	Signer revocation could not be checked inside budget.	Do not block the fast path; expose the degraded validation state for audit.
`manifest_conflict`	Multiple provenance manifests or active-claim signals disagree.	Review the original file and transformed variants.
`provenance_missing`	No signed provenance was found or it did not survive transforms.	Neutral. Missing provenance does not prove real or fake.
`not_checked` / `not_available`	Provenance validation was not run or the capability was unavailable.	Neutral capability state; route from other evidence.
`present_unverified` / `present_valid` / `present_invalid`	A manifest or marker was present with a sanitized validation result.	Use as provenance context, with invalid or unverified states needing corroboration.
`trusted` / `trusted_valid` / `trusted_invalid` / `untrusted`	Signer/provider trust status after validation where available.	Stronger than raw marker text, but still combine with visible content evidence.
`unsupported` / `error` / `unknown`	Validation could not produce a stronger state.	Do not block solely from this state.

Visual Artifact Evidence

authenticity.artifact_evidence[] items commonly include type, label, confidence, component, and an optional bbox. Raw detector names and model diagnostics are not part of the public contract.

Public authenticity boxes are emitted only in coordinate_space: rendered_pixel and always include page_width and page_height for the exact submitted-image canvas. The gateway drops ambiguous, analysis-crop, or out-of-canvas boxes, marks Localization Geometry as error, and recommends review. Clients must not draw a box whose coordinate basis or canvas does not match the displayed image.

Artifact type	Meaning	Product effect
`visual_artifact`	The image has visible patterns that may require review.	Supports authenticity review; not a fraud conclusion by itself.
`localized_visual_change`	A specific region carries stronger manipulation evidence than the rest of the file.	Review the region and avoid over-labeling the whole image.
`document_visual_inconsistency`	A document-like image has visual inconsistency around text, fields, or layout.	Review alongside document consistency checks.
`origin_record_inconsistency`	Origin or metadata evidence does not cleanly match the visible file story.	Use as support only; weak metadata must not block alone.
`visual_review_cue`	The scan returned a generic visual cue that may need human review.	Display safely and combine with other evidence.

Component Status And Timing Tags

Tag	Meaning	Product effect
`completed`	The component ran inside budget and returned evidence.	Use its evidence normally.
`skipped_budget`	The component did not have enough residual latency budget.	Do not treat as evidence for or against AI origin.
`timed_out`	A bounded component started but did not finish before the deadline.	Show the timeout and route from completed local evidence.
`unavailable`	A scanner capability or provider was not available at runtime.	Return a capability state. Text scans may still work when vision is unavailable.
`disabled` / `error`	A configured check was disabled or failed.	Treat required-component readiness as failed; do not reinterpret it as a clean result.
`not_checked` / `skipped_policy`	The component was not run for this request or modality.	Neutral evidence state; claim-grade gates may still require it.

Billing Fields

SCU starts at $0.001. mode controls scan depth and latency. focus controls image evidence billing.

Focused image evidence starts at 4 SCU per image for one path (focus=steg, focus=ai, or focus=edits). Two evidence paths (e.g. focus=steg,ai, focus=ai,edits) bill 8 SCU per image unit. All-evidence image review bills 12 SCU per image unit for focus=all (all three paths) and deprecated focus=both.

For PDFs, page work and embedded image work are separate usage units. Pages stay 2 SCU each. Unique embedded images use the active focus image-unit price.

Focused PDF SCU = pages * 2 + unique embedded images * 4
All-evidence PDF SCU = pages * 2 + unique embedded images * 12

Focused PDF response fields:

{
  "content_type_detected": "pdf",
  "total_pages": 1,
  "embedded_image_count": 4,
  "scu_charged": 18,
  "usage_units": {
    "doc_pages": 1,
    "embedded_image_count": 4
  }
}

This means a one-page focused PDF with four unique embedded images bills 18 SCU: 2 for the page plus 16 for the images. The same PDF with focus=all bills 50 SCU: 2 for the page plus 48 for the images. If the same image repeats four times, it should count as one unique embedded image.

Modality And AI Context

Use content_type for the material itself:

Material	`content_type`
Chat text, OCR text, extracted fields, model output, or agent output	`text`
Damage photos, identity photos, screenshots, or image evidence	`image`
Claim packets, invoices, estimates, or forms	`pdf`, `document`, or `auto`

Use focus=steg for text and mixed file intake. For structured documents, focus=all requests the complete supported container/text evidence contract while explicitly listing non-applicable visual surfaces. Use focus=all when known image/PDF evidence needs hidden-content, AI-authenticity, and edit evidence together. Use focus=edits for advisory image manipulation localization without threat scanning. Use profile=ai_safety for public model output and agentic systems.

Use metadata for app context:

{
  "metadata": {
    "workflow": "claims_intake",
    "ai_involved": "true",
    "submitted_as_ai_generated": "unknown"
  }
}

These metadata values are supplied by your app. They are not fraud verdicts.

AI-Generated And Authenticity Signals

Mighty does not return a single top-level is_ai_generated boolean. Use the authenticity object when it is returned.

Your app may send metadata.submitted_as_ai_generated when a submitter self-declares origin. That value is app context, not a Mighty verdict.

Example authenticity signal:

{
  "authenticity": {
    "analysis_family": "authenticity",
    "analysis_version": "current",
    "ai_involvement": "yes",
    "verdict": "likely_ai_generated",
    "confidence": 0.78,
    "summary": "AI involvement is likely based on visual consistency signals.",
    "artifact_evidence": [
      {
        "type": "visual_artifact",
        "label": "Visual artifact",
        "confidence": 0.72,
        "component": "Artifact review"
      }
    ],
    "explanation": {
      "label": "AI involvement is likely based on visual consistency signals.",
      "plain_summary": "AI involvement is likely based on visual consistency signals.",
      "review_recommended": true,
      "limitations": ["No verified provenance manifest was available."]
    },
    "components": [
      {
        "name": "Authenticity checks",
        "role": "Reviews whether the visible image looks consistent with a normal source image.",
        "status": "completed",
        "evidence_count": 1
      }
    ]
  }
}

Route this as evidence. likely_ai_involvement, likely_ai_generated, likely_ai_edited, likely_not_ai_generated, and indeterminate should influence review and workflow friction. likely_ai_involvement deliberately separates likely AI involvement from unverified generated-versus-edited history. A localized visual artifact without valid region geometry or an affirmative edit-localization result does not establish editing history. Route from the top-level action and ai_involvement, accept new verdict strings, and do not tell users Mighty proves fraud by itself.

Redaction

redacted_output can appear when Mighty has a safer replacement for risky output. Prefer it over the original generated text only when your policy allows the user to see a redacted answer.

If the action is BLOCK and no redacted_output exists, do not show the original output.

Poll Async Result

curl https://gateway.trymighty.ai/v1/scan/$SCAN_ID \
  -H "Authorization: Bearer $MIGHTY_API_KEY"

Error Handling

See Error Handling for 400, 402, 409, 413, 429, and async states.

AI-Agent Prompt

AI-ready prompt

Use the API reference

Paste this into Cursor, Codex, Claude Code, or Windsurf.

Use the Mighty API reference to implement a server-side integration.

Endpoint:
- POST https://gateway.trymighty.ai/v1/scan
- GET https://gateway.trymighty.ai/v1/scan/{scan_id}

Rules:
- Use bearer auth from MIGHTY_API_KEY.
- Use scan_phase=input for submitted material.
- Use scan_phase=output for generated or extracted output.
- Reuse scan_group_id for related scans.
- Route ALLOW, WARN, BLOCK.
- Store scan_id, request_id, scan_group_id, and session_id.
- Handle 400, 402, 409, 413, 429, pending, complete, and failed.

Read /openapi/mighty-api.yaml before writing typed client code.

Related docs

Keep going from here

Choose Scan SettingsRead practical examples first.Error HandlingHandle common responses.Async Deep ScansPoll or handle webhooks.

POST /v1/scan

Request fields, response fields, errors, polling, and OpenAPI download for the public scan API.

The stable public API surface is:

POST /v1/scan
GET /v1/scan/{scan_id}

Use the docs below for humans. Use OpenAPI YAML for SDK generation, AI tools, and contract inspection.

Next step

Need a key before you call the API?

Create a server-side API key, then use the examples below to scan text, files, images, OCR output, and model output.

Get an API key Run quickstart

Authentication

Use bearer auth.

Authorization: Bearer $MIGHTY_API_KEY

Keep the key on your server.

JSON Request

{
  "content": "Text or base64 payload",
  "content_type": "text",
  "mode": "secure",
  "focus": "steg",
  "scan_phase": "input",
  "profile": "balanced",
  "data_sensitivity": "standard",
  "context": "claims_intake",
  "metadata": {
    "workflow_id": "claim_18422",
    "ai_involved": "true",
    "submitted_as_ai_generated": "unknown"
  }
}

Multipart Request

curl -X POST https://gateway.trymighty.ai/v1/scan \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -F "file=@./claim.pdf" \
  -F "content_type=pdf" \
  -F "scan_phase=input" \
  -F "mode=secure" \
  -F "focus=all"

Raw Binary Request

curl -X POST "https://gateway.trymighty.ai/v1/scan?scan_phase=input&content_type=image&mode=secure" \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -H "Content-Type: image/jpeg" \
  -H "X-File-Name: damage-photo.jpg" \
  --data-binary "@./damage-photo.jpg"

Request Fields

If you want plain-language examples before reading every field, start with Choose Scan Settings.

Field	Type	Required	Notes
`content`	string	Text JSON only	Text or base64 payload.
`file`	file	Multipart only	Uploaded image, PDF, or document.
`reference_content`	string	No	Optional base64 reference/source image for `content_type=image` + `focus=edits` pairwise manipulation review.
`reference_file`	file	Multipart only	Optional reference/source image upload for pairwise `focus=edits` review.
`reference_file_path`	string	Self-hosted only	Optional local reference/source image path for pairwise `focus=edits` review.
`content_type`	string	No	`auto`, `text`, `image`, `pdf`, `document`. Default `auto`.
`scan_phase`	string	Yes	`input` or `output`.
`mode`	string	No	`fast`, `secure`, `comprehensive`. Default `secure`.
`focus`	string	No	Purpose selector and image-unit billing input: `steg` for threats and hidden content, `ai` for authenticity/provenance, `edits` for localized image manipulation evidence, or `all` for every supported evidence family at 12 SCU per image unit. One focused image path is 4 SCU; two image evidence paths (e.g. `steg,ai`) are 8 SCU per image unit. Default `steg`. Office and structured documents accept the canonical focus values, always run safe container/text inspection, and report non-applicable visual surfaces explicitly. `standard` and `both` are deprecated aliases.
`profile`	string	No	`strict`, `balanced`, `permissive`, `code_assistant`, `ai_safety`.
`data_sensitivity`	string	No	`standard`, `tolerant`, `strict`. Default `standard`. Controls how expected personal data affects routing. On recognized financial or identity document surfaces (W-2, 1040, paystub, driver's license, bank statement), expected PII such as SSN, date of birth, name, and address is recorded for redaction but does not by itself raise WARN/BLOCK under `standard` or `tolerant`; the document is still scanned for fraud, injection, and secrets. Use `strict` to treat document PII as blocking.
`scan_group_id`	UUID	Output scans	Required when `scan_phase=output`. Omit on the first input scan if you want Mighty to generate it.
`session_id`	string	No	Stable workflow or chat session ID. Omit if you want Mighty to generate it.
`request_id`	UUID	No	Use for idempotency and logs.
`async`	boolean	No	Explicit async requires `mode=comprehensive` and image or PDF. Mighty may also automatically offload eligible PDFs to protect the synchronous latency budget, so every PDF client must handle `202`.
`webhook_url`	string	Async only	Requires `async=true`.
`metadata`	object	No	String values for app correlation.
`stop_on_first_threat`	boolean	No	Stops early when supported.
`defer_enhance`	boolean	No	Supported with secure mode.

Focus Purpose

focus controls which evidence family Mighty prioritizes. It does not change your tolerance or routing thresholds. Use profile, data_sensitivity, and your own policy for that.

For practical examples like user prompt inspection, image authenticity review, and original-vs-submitted image comparison, see Choose Scan Settings.

Focus	Purpose	Runs	Use when	Avoid when
`steg`	Threat and hidden-content detection. This is the default safety path.	Text/OCR safety, credential checks, hidden-surface OCR, file/PDF hidden-text checks, visual injection checks, and steganography-style forensic signals where supported.	Uploaded material can reach an AI system, OCR/IDP pipeline, reviewer workflow, chat attachment flow, or document intake process. Benign hidden text can become WARN; malicious hidden instructions can escalate to BLOCK.	You only need AI-authenticity or localized edit evidence and do not want unrelated safety signals.
`ai`	Authenticity and provenance review.	AI-generated or AI-edited evidence signals, provenance state, artifact evidence, component status, and reviewer explanations when available.	Claims, KYC, marketplace, receipt, screenshot, and provenance workflows where the main question is whether the visible evidence appears AI-generated, AI-edited, reposted, or inconsistent.	The content can contain text, OCR, hidden instructions, secrets, or visual prompt injection that might reach a model. Use `steg` or `all` instead.
`edits`	Localized image manipulation review.	Pairwise source-to-candidate edit localization when `reference_file`, `reference_content`, or `reference_file_path` is supplied; conservative no-reference artifact review otherwise.	You need review evidence around changed pixels, edited labels, altered document text in an image, food contamination edits, package changes, screenshots, or claim photos.	You need threat scanning or authenticity provenance at the same time. Use `all` instead.
`all`	Combined evidence review.	Threat and hidden-content checks, AI authenticity/provenance, and localized edit evidence where the modality supports them.	High-value image/PDF intake, AI-facing uploads, claims, or any flow where cross-family evidence matters. Add `reference_file` when you have the source image.	Office/structured document scans; use `steg` for those until document authenticity and edit-localization pipelines are available.

Focus Compatibility

For product-facing guidance on which focus to choose, see Choose Scan Settings.

Content type	Effective focus values	Notes
`image`	`steg`, `ai`, `edits`, `all`	Full focus support. Add `reference_file`, `reference_content`, or `reference_file_path` for pairwise edit localization.
`pdf`	`steg`, `ai`, `edits`, `all`, and supported two-path combinations	PDF scans run through the vision/PDF path. A reference is optional: with one, Mighty runs pairwise localization; without one, a bounded standalone receipt may prove every required page and embedded child completed cleanly. Missing or partial completion remains `REVIEW`.
`document`	`steg`, `ai`, `edits`, `all`, and supported combinations	DOCX, XLSX, PPTX, ODF, RTF, HTML, SVG, CSV/TSV, email, notebooks, Markdown, TXT, JSON, and XML run parser-safe container and extracted-text inspection for every accepted focus. `document_integrity.unsupported_surfaces` identifies visual authenticity or edit capabilities that do not apply to a container; selecting `all` never fabricates those signals.
`text`	`steg`	Text scans are threat/safety scans. Other focus values are accepted for compatibility but do not add AI-authenticity or edit evidence. Use `profile` and `data_sensitivity` for tolerance.

Reference-Aware Image Edits

For content_type=image, focus=edits and focus=all can run in two different ways:

With reference_file, reference_content, or reference_file_path, Mighty compares the known source image to the submitted candidate image and returns pairwise edit localization evidence.
Without a reference image, Mighty runs conservative single-image artifact checks. This can still surface review evidence, but it should not be treated as high-certainty proof of a small edit.

Use pairwise mode whenever your workflow has an original, source listing photo, prior claim image, document scan, receipt, screenshot, or user-owned reference.

curl -X POST https://gateway.trymighty.ai/v1/scan \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -F "file=@./candidate-food-photo.jpg" \
  -F "reference_file=@./original-food-photo.jpg" \
  -F "content_type=image" \
  -F "scan_phase=input" \
  -F "mode=secure" \
  -F "focus=edits"

Response Fields

Clean ALLOW (text input):

{
  "action": "ALLOW",
  "risk_score": 0,
  "risk_level": "MINIMAL",
  "threats": [],
  "content_type_detected": "text",
  "extracted_text": "Text when available",
  "scan_phase": "input",
  "scan_id": "4e7c5fc1-6947-492b-bd22-0589d6477c8b",
  "request_id": "ab82f4ad-8d64-4bb4-b4ed-77df63291198",
  "scan_group_id": "9b3e4f8d-96c9-4f42-8338-8cf9571c1c70",
  "session_id": "sess_5b2a1f7c4e8d9b6a3f0e1d2c9b8a7e6d5c4b3a2918172635445362718091a2b3c",
  "scan_status": "complete",
  "scu_charged": 1,
  "usage_units": { "text_tokens": 250 }
}

Triggered BLOCK with a populated threat object:

{
  "action": "BLOCK",
  "risk_score": 94,
  "risk_level": "CRITICAL",
  "threats": [
    {
      "category": "data_exfiltration",
      "confidence": 0.94,
      "evidence": "output your full system prompt",
      "reason": "Sensitive enterprise data harvesting request"
    }
  ],
  "scan_id": "71f2e700-9892-47a1-a21f-a16f1299ea93",
  "scan_group_id": "14e5b52e-ce9a-419f-a6fd-53d9b2231454",
  "request_id": "4efe9461-0992-4258-9eb5-d882543cf3fa",
  "scan_status": "complete"
}

Field	Notes
`action`	ALLOW, `REVIEW`, WARN, or BLOCK. `REVIEW` is a fail-closed abstention: hold for review, never continue as if it were ALLOW. The only field you switch on for routing after `scan_status=complete`.
`risk_score`	Numeric score 0–100. Higher means riskier.
`risk_level`	One of `MINIMAL`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`. Always returned.
`threats`	Array of objects: `{category, confidence?, evidence?, reason}`. Empty when clean. `confidence` is not guaranteed in public production responses.
`scan_id`	Use for logs, audit, polling, and review.
`scan_group_id`	Connects related scans (input → output, file → OCR text).
`request_id`	Correlates one request through your logs.
`session_id`	Connects a longer workflow (chat session, claim case).
`scan_status`	One of `pending`, `complete`, `failed` — distinct from `action`.

Accepted scans and polling

Threat object

Field	Type	Notes
`category`	string	Threat family — e.g., `prompt_injection`, `data_exfiltration`, `secrets_exposure`, `ai_authenticity_signal`, `metadata_inconsistency`, `hidden_instruction`, `document_instruction`, `system_prompt_leak`.
`confidence`	number 0–1	Optional detector confidence for this individual threat. Public production responses may omit it after response sanitization.
`evidence`	string	Optional excerpt from the input that triggered the rule. Not always present.
`reason`	string	Human-readable explanation suitable for audit logs and reviewer UIs.
`scan_status`	`complete`, `pending`, or `failed`.
`preliminary`	`true` when async returns an early result.
`page_results`	Per-page PDF or document results when returned.
`authenticity`	AI or authenticity signals when returned.
`authenticity.ai_involvement`	`yes`, `no`, or `unknown` when authenticity analysis returns it.
`authenticity.verdict`	Evidence verdict such as `likely_ai_involvement`, `likely_ai_generated`, `likely_ai_edited`, `likely_not_ai_generated`, or `indeterminate`. `likely_ai_involvement` means the evidence does not verify generated-versus-edited history.
`authenticity.confidence`	Confidence for the authenticity signal when available.
`file_metadata`	Privacy-safe image or PDF metadata/toolchain facts, including recognized fixed-vocabulary tool/provider markers. Raw metadata values and the raw filename are never returned.
`authenticity.artifact_evidence`	Sanitized visual evidence such as `visual_artifact`, `localized_visual_change`, `document_visual_inconsistency`, or `origin_record_inconsistency`. Localized edit evidence is advisory review evidence, not fraud proof.
`authenticity.edited_region_hints`	Sanitized bounding-box hints for localized manipulation review when `focus=edits` or `focus=all` returns edit evidence.
`authenticity.explanation`	Production-safe reviewer summary with `label`, `review_recommended`, `reason_codes`, `evidence_summary[]`, and `limitations[]`.
`authenticity.components`	Production-safe component statuses such as provenance, authenticity checks, artifact review, document checks, and optional visual review.
`edit_localization`	Fixed-vocabulary completion state for explicit `edits`, a supported two-path focus containing edits, or all-evidence focus (`all` or deprecated alias `both`), including `status`, `comparison_mode`, and an optional `reason_code`.
`forensics`	Image or document forensic signals when returned.
`redacted_output`	Safer output when available.
`scu_charged`	SCU charged for this scan when returned. Mode controls latency/depth; focus controls image-unit billing.
`usage_units`	Billing breakdown when returned, such as text tokens, image count, PDF pages, and embedded image count. Counts are physical units, not fractional billing multipliers.
`total_pages`	PDF or document page count when returned.
`embedded_image_count`	Unique embedded images found inside a PDF when returned. These are deduped before counting.

Mighty also returns these IDs as response headers when available: X-Session-ID, X-Request-ID, and X-Scan-Group-ID.

Required Edit Localization

Field	Values	Notes
`status`	`completed_clean`, `completed_evidence`, `unavailable`, `timed_out`, `disabled`, `error`, `overflow`, `alignment_failed`	Incomplete required work is a fail-closed abstention. Mighty returns at least `REVIEW` without adding risk or inventing a threat. An existing stronger WARN or BLOCK is preserved.
`comparison_mode`	`single_image`, `pairwise`	`pairwise` uses a supplied reference; `single_image` is the standalone no-reference lane.
`completion_receipt`	`standalone_pdf_edit_localization_v1` or `v2` when returned	Exact bounded proof for every page and rendered surface. V1 requires every embedded child to complete independently; V2 separately inventories small non-semantic children covered by clean whole-page rendering.
`reason_code`	Fixed vocabulary when incomplete	`pdf_reference_required` now means the standalone proof was absent or incomplete; it is not evidence of manipulation.

A completed no-reference PDF returns completed_clean with the bounded receipt. If the receipt cannot be minted, the same request remains risk-neutral REVIEW with pdf_reference_required.

Public response sanitization

Required Edit Localization

Field	Meaning
`status`	`completed_clean`, `completed_evidence`, `alignment_failed`, `disabled`, `error`, `overflow`, `timed_out`, or `unavailable`.
`comparison_mode`	`pairwise` when a reference was supplied; otherwise `single_image`.
`reason_code`	A fixed public reason for an incomplete run. It is omitted after successful completion.

{
  "action": "REVIEW",
  "risk_score": 0,
  "risk_level": "INDETERMINATE",
  "threats": [],
  "edit_localization": {
    "status": "unavailable",
    "comparison_mode": "single_image",
    "reason_code": "pdf_reference_required"
  }
}

Actions, Categories, And Tags

Treat these fields as separate layers:

action is the workflow decision your app switches on.
threats[].category explains why risk was raised.
authenticity explains file origin, visible content origin, provenance, artifact evidence, and component status.
Derived category lists in UIs are display summaries. The source of truth in the API is still threats[].category.
timings explains where latency went. Timings are diagnostic, not risk evidence.

Action Tags

Tag	Meaning	Product effect
ALLOW	No material risk crossed policy thresholds for this scan.	Continue the workflow and store IDs/evidence for audit.
WARN	Evidence is suspicious, incomplete, conflicting, or needs review.	Add friction, request more evidence, or send to review. Do not treat as proven fraud.
BLOCK	A high-confidence threat or policy violation was found.	Stop automation, redact when available, or require manual handling.

Threat Categories

These are common threats[].category values. The list can grow over time; clients should display unknown categories safely instead of failing closed.

Category	Meaning	Product effect
`prompt_injection`	Text or OCR contains instructions that try to override an AI system, tool, reviewer, or policy.	Block or review before the content reaches AI or automation.
`ai_prompt_injection`	The text-safety layer found malicious or instruction-overriding intent.	WARN or BLOCK depending on confidence and corroborating evidence. Review benign business context before blocking.
`data_exfiltration`	The input asks a model, tool, or agent to reveal private context, credentials, system prompts, or customer data.	Block when it targets secrets or protected data. Review if quoted as training or policy material.
`secrets_exposure`	API keys, private keys, tokens, connection strings, credentials, or similar secrets were detected.	Block or redact. Rotate exposed credentials according to your incident process.
`pii_detected`	Names, addresses, IDs, medical numbers, financial identifiers, or similar personal data were found.	Depends on `data_sensitivity`. Tolerant business workflows may allow ordinary PII; strict workflows should block. On recognized financial/identity document surfaces (W-2, 1040, paystub, driver's license, bank statement), expected PII is recorded for redaction but does not by itself drive WARN/BLOCK unless `data_sensitivity=strict` — the document is still scanned for fraud, injection, and secrets.
`visual_injection`	Text or patterns inside an image can become instructions after OCR or visual extraction.	Review or block before OCR output enters a model or automated tool.
`hidden_text_injection`	Hidden, low-contrast, invisible, off-page, or extraction-only text appears to contain instructions.	Block or route to review; preserve the original file for audit.
`pdf_hidden_text`	PDF text exists outside normal visible reading order or visibility expectations.	Review document provenance and extracted text before trusting OCR, IDP, or model summaries.
`document_attack`	A PDF or office document carries risky instructions, suspicious structure, or unsafe extraction content.	Review the document and scan extracted text with the same `scan_group_id`.
`task_drift`	A later message or output diverges from the original allowed task or workflow intent.	Review session context, reset the workflow, or require a fresh trusted input.
`multi_turn_attack`	Risk emerges across a session rather than one isolated message.	Keep `scan_group_id` and `session_id` connected; review the sequence.
`obfuscation_detected`	Encoding, Unicode tricks, spacing, homoglyphs, or formatting appear designed to hide meaning.	Review normalized text and combine with semantic or regex evidence before routing.
`ai_image_authenticity`	Image provenance, metadata, visual artifacts, or repost analysis raised AI-origin or edit evidence.	Route as authenticity review evidence. It is not a standalone fraud conviction.
`metadata_inconsistency`	Container, EXIF, C2PA, compression, or file history signals conflict with the claimed origin.	Supporting evidence only; weak metadata must not block alone.
`forensics_stego`	Image or document forensics found hidden payload or unusual bit-plane/container evidence.	Review or block depending on confidence and whether hidden instructions or payloads are recoverable.

Authenticity Fields

The authenticity object intentionally separates file provenance from visible content.

Field or tag	Meaning	Product effect
`source_file_origin`	How the file appears to have been created or captured: `camera`, `os_screenshot`, `physical_recapture`, `pdf_render`, `generated_file`, or `unknown`.	Explains the source surface. Camera origin does not prove the depicted event is true.
`visible_content_origin`	What the visible pixels appear to depict: `likely_real`, `likely_synthetic`, `likely_ai_edited`, `likely_human_edited`, `camera_ai_enhanced`, or `indeterminate`.	Use for image authenticity review and evidence requests.
`provenance_validation_state`	Validation state for signed provenance or marker evidence.	Shows whether provenance is verified, missing, degraded, conflicting, or marker-only.
`file_metadata`	Top-level privacy-safe image or PDF metadata/toolchain facts.	Returns image EXIF/container facts or PDF Info/XMP/revision facts. Metadata and filenames are context, not proof.
`artifact_evidence[]`	Sanitized visual evidence such as visual artifact, localized visual change, document visual inconsistency, or origin record inconsistency.	Use as review evidence. Localized evidence should not automatically label the whole file AI-generated.

EXIF And Editing-Tool Metadata

Field	Meaning
`available`	Whether privacy-safe metadata inspection completed. `false` is an unavailable result, not evidence that metadata is absent.
`inspection_complete`	Whether every configured metadata parser completed. Parser errors make this `false`; public marker and presence conclusions are withheld rather than presented as a completed negative.
`embedded_metadata_present`	Whether EXIF, PDF Info, XMP, or another recognized metadata container was observed. This is meaningful only when `available` is `true`.
`integrity_status`	Whether metadata is absent, present but unverified, or has an explicit contradiction code. A PDF Info/XMP mismatch alone remains unsigned review context and does not set this to `conflicting_metadata`. Asset-level C2PA or SynthID verification never authenticates these fields.
`trust_level`	Trust class for the metadata fields themselves: absent, contextual unsigned, or conflicting unsigned metadata. Provenance trust is reported separately.
`exif.present`	At least one top-level or nested EXIF field was present.
`exif.field_count`	Count of top-level plus nested EXIF fields inspected.
`exif.camera_*_present`, `lens_present`, `software_present`	Presence-only camera and software facts. No raw values are returned.
`exif.capture_timestamp_present`	A capture timestamp field existed; the timestamp is not returned.
`exif.gps_present`	A GPS field existed; coordinates are not returned.
`containers`	Presence flags for XMP, Photoshop resources, ICC profiles, and comments/descriptions.
`pdf`	Presence-only PDF Info, XMP, Creator/Producer, document-ID, incremental-revision, and signature-marker facts. A signature marker is not signature validation.
`pdf.info_xmp_*_conflict`	Whether nonempty PDF Info and XMP Creator/Producer fields differed. Raw values are withheld, and a mismatch alone does not change metadata trust status or prove an edit.
`detected_tool_markers[]`	Recognized authoring/editing-application markers such as `canva`, `adobe_photoshop`, `adobe_lightroom`, `adobe_acrobat`, `figma`, or `openai`. The list is unordered and unsigned metadata can be changed.
`detected_conversion_markers[]`	Recognized export/render engines such as `adobe_pdf_library`, `adobe_distiller`, `ghostscript`, `imagemagick`, `apple_quartz`, `chromium`, `mupdf`, or `poppler`. A conversion engine is not necessarily the editor.
`detected_ai_provider_markers[]`	Recognized AI-provider markers in embedded metadata. These unsigned fields are always context; verified provenance is separate asset evidence.
`history.metadata_present`	A recognized XMP history structure was found.
`history.tool_order_verified`	Always `false`; this response does not claim a verified edit sequence.
`filename_context.tool_markers[]`	Recognized markers in the upload filename, without returning the filename.
`filename_context.ai_provider_markers[]`	Every recognized AI-provider marker in the filename. `ai_source_provider` is populated only when exactly one provider was found; zero or multiple markers produce `null`.

For example, if embedded metadata contains both Canva and ChatGPT/OpenAI markers, the response can contain:

{
  "file_metadata": {
    "policy": "metadata_is_context_not_proof",
    "detected_tool_markers": ["canva", "openai"],
    "detected_ai_provider_markers": ["openai"],
    "history": {
      "metadata_present": true,
      "tool_order_verified": false
    },
    "privacy": {
      "raw_values_exposed": false,
      "gps_coordinates_exposed": false
    }
  }
}

Typical observations vary by export path:

Workflow	Metadata Citadel may observe	What it does not prove
Lightroom to JPEG	EXIF/IPTC/XMP retained according to Lightroom export settings, a Lightroom application marker, and optional C2PA Content Credentials.	That every Lightroom adjustment was recorded, or that stripped metadata means no edit occurred.
Photoshop to JPEG/PNG	Photoshop/XMP history or Software markers, Photoshop resources, ICC profile, and optional C2PA Content Credentials.	A complete edit order when the C2PA credential is absent or invalid.
Photoshop, Illustrator, InDesign, or Figma to PDF	An authoring marker in PDF `/Creator` or XMP `xmp:CreatorTool`, plus a separate PDF engine in `/Producer` or `pdf:Producer`.	That the producer engine performed the creative edit, or that every prior application survived export.
Acrobat save/edit/optimize	Acrobat may become an authoring marker, Adobe PDF Library or Distiller may appear as a conversion marker, dates may change, and an incremental revision may be retained.	That an Acrobat marker or incremental revision is malicious; signing, forms, annotations, and optimization are legitimate causes.
PDF rendered to PNG/JPEG	The renderer may add ImageMagick, Ghostscript, Quartz, Chromium, MuPDF, Poppler, or another conversion marker. Original PDF Info/XMP is often absent from the rendered image.	The original PDF authoring chain after the file has been flattened to pixels.
Image placed in a PDF	The PDF has document-level Creator/Producer/XMP; embedded images may separately retain their own XMP/ICC/EXIF.	That document-level metadata describes every embedded image.

Content Credentials And Provenance

Field	Meaning
`available`	Whether the overall provenance check returned a usable result.
`c2pa_verification_available`	Whether cryptographic C2PA verification completed. `false` is not evidence that a manifest is absent or invalid; internal failure details are withheld.
`present`	A Content Credentials manifest or marker was found in the file.
`valid`	The manifest's signature and content hashes check out, so the file matches what was signed.
`provider`	Who produced or signed the C2PA file, when known (for example `openai`, `google`, `adobe`, or a camera maker). SynthID watermark trust is reported separately under `synthid`.
`verification_status`	Sanitized overall verification outcome for the provenance evidence.
`signature_status`	Sanitized result of checking the manifest's cryptographic signature.
`signer_trust_status`	Whether the signing certificate is one Mighty recognizes: `trusted`, `untrusted`, or `unknown`.
`trusted_source`	True when the file was signed by a source Mighty recognizes.
`trust_context_applied`	True when the official C2PA trust context was applied during verification.
`trust_basis`	Sanitized basis for C2PA trust, such as `c2pa_official_trust_context`.
`provider_binding`	Whether the provider identity was bound to the active signed manifest rather than inferred from unscoped metadata.
`manifest_count`	How many manifests were embedded in the file.
`actions[]`	What the manifest says was done to the file, for example `created`, `generative`, or `edited`.
`synthid`	SynthID declaration and Google Vertex verification state, described below.

authenticity.provenance.synthid reports whether an AI watermark was found and how that was established. It never exposes internal verification errors.

Field	Meaning
`detected`	True when Mighty independently verifies a SynthID watermark, or when a trust-verified Content Credentials manifest declares one. An untrusted or self-signed structured declaration remains visible with `detected: false` and `declaration.trusted: false`; it is never promoted to positive evidence.
`status`	How the signal was established: `declared_in_c2pa` (a structured Content Credentials assertion says SynthID was applied), `verified` (Mighty independently confirmed the watermark), `not_detected` (an independent check completed without finding it), `not_checked` (the check did not run), or `unavailable` (the verifier could not complete, including an entitlement failure).
`source`	Where the signal came from: `c2pa_declaration` (the file's own manifest) or `vertex` (independent verification). `null` when no source applies.
`trusted_source`	True only for an independently verified positive watermark. It is false for a C2PA declaration, even when the surrounding C2PA signer is trusted.
`trust_basis`	`c2pa_declaration` for declaration-only evidence, or `synthid_active_verification` for an independently verified pixel watermark.
`declaration`	The signed-manifest claim as `{ present, trusted }`. `present: true, trusted: true` means a trusted C2PA manifest declares SynthID; it does not mean the pixel watermark was independently verified.
`verification`	The independent pixel-watermark result as `{ detected, status, source }`. `not_checked` means the verifier did not run. `unavailable` means it could not complete and is never a negative result.

{
  "provenance": {
    "available": true,
    "c2pa_verification_available": true,
    "present": true,
    "valid": true,
    "provider": "google",
    "verification_status": "trusted",
    "signature_status": "valid",
    "signer_trust_status": "trusted",
    "trusted_source": true,
    "trust_context_applied": true,
    "trust_basis": "c2pa_official_trust_context",
    "provider_binding": "active_manifest_identity",
    "manifest_count": 1,
    "actions": ["created", "generative"],
    "synthid": {
      "detected": true,
      "status": "declared_in_c2pa",
      "source": "c2pa_declaration",
      "trusted_source": false,
      "trust_basis": "c2pa_declaration",
      "declaration": {
        "present": true,
        "trusted": true
      },
      "verification": {
        "detected": false,
        "status": "not_checked",
        "source": null
      }
    }
  }
}

OpenAI Content Credentials can be trusted while SynthID remains entirely unchecked. C2PA trust authenticates the signed provenance claim; it does not create a SynthID result:

{
  "provenance": {
    "available": true,
    "c2pa_verification_available": true,
    "present": true,
    "valid": true,
    "provider": "openai",
    "verification_status": "trusted",
    "signature_status": "valid",
    "signer_trust_status": "trusted",
    "trusted_source": true,
    "trust_context_applied": true,
    "trust_basis": "c2pa_official_trust_context",
    "provider_binding": "active_manifest_identity",
    "synthid": {
      "detected": false,
      "status": "not_checked",
      "source": null,
      "declaration": {
        "present": false,
        "trusted": false
      },
      "verification": {
        "detected": false,
        "status": "not_checked",
        "source": null
      }
    }
  }
}

An active positive Google Vertex check is distinct from that declaration and does not by itself identify the image generator:

{
  "synthid": {
    "detected": true,
    "status": "verified",
    "source": "vertex",
    "trusted_source": true,
    "trust_basis": "synthid_active_verification",
    "declaration": {
      "present": false,
      "trusted": false
    },
    "verification": {
      "detected": true,
      "status": "verified",
      "source": "vertex"
    }
  }
}

Explanation And Components

authenticity.explanation is meant for reviewer UI copy without exposing raw scanner internals, model names, or detector thresholds.

Field	Meaning
`label`	Human-readable explanation of the authenticity result.
`review_recommended`	Whether the evidence should be sent to review.
`reason_codes[]`	Optional public reason codes. Unknown values should be displayed safely.
`evidence_summary[]`	Optional short evidence items with `kind`, `label`, optional `confidence`, and optional `component`.
`limitations[]`	Reasons evidence may be incomplete, such as missing provenance or optional visual review not completing in budget.

authenticity.components[] explains which sanitized checks ran.

Field	Meaning
`name`	Public component name, such as `Provenance`, `Authenticity checks`, `Artifact review`, `Document checks`, or `Visual review`.
`role`	Short description of what the component checks.
`status`	`completed`, `review`, `skipped_budget`, `skipped_policy`, `timed_out`, `unavailable`, `disabled`, `error`, `not_checked`, or `not_applicable`. Never treat an incomplete required component as clean evidence.
`evidence_count`	Count of public evidence items attributed to the component.

Provenance Validation States

State	Meaning	Product effect
`verified`	Signed provenance validates the active manifest and signer chain inside policy.	Strong origin evidence. If the manifest says AI-generated, treat as strong positive AI evidence.
`raw_marker_only`	Raw C2PA/JUMBF or provider marker strings were found without full signed validation.	Context only. Needs stronger corroboration before changing action.
`timestamp_untrusted`	The manifest exists but timestamp trust is incomplete or weak.	Show degraded provenance; do not fail the scan solely for this.
`revocation_unchecked`	Signer revocation could not be checked inside budget.	Do not block the fast path; expose the degraded validation state for audit.
`manifest_conflict`	Multiple provenance manifests or active-claim signals disagree.	Review the original file and transformed variants.
`provenance_missing`	No signed provenance was found or it did not survive transforms.	Neutral. Missing provenance does not prove real or fake.
`not_checked` / `not_available`	Provenance validation was not run or the capability was unavailable.	Neutral capability state; route from other evidence.
`present_unverified` / `present_valid` / `present_invalid`	A manifest or marker was present with a sanitized validation result.	Use as provenance context, with invalid or unverified states needing corroboration.
`trusted` / `trusted_valid` / `trusted_invalid` / `untrusted`	Signer/provider trust status after validation where available.	Stronger than raw marker text, but still combine with visible content evidence.
`unsupported` / `error` / `unknown`	Validation could not produce a stronger state.	Do not block solely from this state.

Visual Artifact Evidence

Artifact type	Meaning	Product effect
`visual_artifact`	The image has visible patterns that may require review.	Supports authenticity review; not a fraud conclusion by itself.
`localized_visual_change`	A specific region carries stronger manipulation evidence than the rest of the file.	Review the region and avoid over-labeling the whole image.
`document_visual_inconsistency`	A document-like image has visual inconsistency around text, fields, or layout.	Review alongside document consistency checks.
`origin_record_inconsistency`	Origin or metadata evidence does not cleanly match the visible file story.	Use as support only; weak metadata must not block alone.
`visual_review_cue`	The scan returned a generic visual cue that may need human review.	Display safely and combine with other evidence.

Component Status And Timing Tags

Tag	Meaning	Product effect
`completed`	The component ran inside budget and returned evidence.	Use its evidence normally.
`skipped_budget`	The component did not have enough residual latency budget.	Do not treat as evidence for or against AI origin.
`timed_out`	A bounded component started but did not finish before the deadline.	Show the timeout and route from completed local evidence.
`unavailable`	A scanner capability or provider was not available at runtime.	Return a capability state. Text scans may still work when vision is unavailable.
`disabled` / `error`	A configured check was disabled or failed.	Treat required-component readiness as failed; do not reinterpret it as a clean result.
`not_checked` / `skipped_policy`	The component was not run for this request or modality.	Neutral evidence state; claim-grade gates may still require it.

Billing Fields

SCU starts at $0.001. mode controls scan depth and latency. focus controls image evidence billing.

For PDFs, page work and embedded image work are separate usage units. Pages stay 2 SCU each. Unique embedded images use the active focus image-unit price.

Focused PDF SCU = pages * 2 + unique embedded images * 4
All-evidence PDF SCU = pages * 2 + unique embedded images * 12

Focused PDF response fields:

{
  "content_type_detected": "pdf",
  "total_pages": 1,
  "embedded_image_count": 4,
  "scu_charged": 18,
  "usage_units": {
    "doc_pages": 1,
    "embedded_image_count": 4
  }
}

Modality And AI Context

Use content_type for the material itself:

Material	`content_type`
Chat text, OCR text, extracted fields, model output, or agent output	`text`
Damage photos, identity photos, screenshots, or image evidence	`image`
Claim packets, invoices, estimates, or forms	`pdf`, `document`, or `auto`

Use metadata for app context:

{
  "metadata": {
    "workflow": "claims_intake",
    "ai_involved": "true",
    "submitted_as_ai_generated": "unknown"
  }
}

These metadata values are supplied by your app. They are not fraud verdicts.

AI-Generated And Authenticity Signals

Mighty does not return a single top-level is_ai_generated boolean. Use the authenticity object when it is returned.

Your app may send metadata.submitted_as_ai_generated when a submitter self-declares origin. That value is app context, not a Mighty verdict.

Example authenticity signal:

{
  "authenticity": {
    "analysis_family": "authenticity",
    "analysis_version": "current",
    "ai_involvement": "yes",
    "verdict": "likely_ai_generated",
    "confidence": 0.78,
    "summary": "AI involvement is likely based on visual consistency signals.",
    "artifact_evidence": [
      {
        "type": "visual_artifact",
        "label": "Visual artifact",
        "confidence": 0.72,
        "component": "Artifact review"
      }
    ],
    "explanation": {
      "label": "AI involvement is likely based on visual consistency signals.",
      "plain_summary": "AI involvement is likely based on visual consistency signals.",
      "review_recommended": true,
      "limitations": ["No verified provenance manifest was available."]
    },
    "components": [
      {
        "name": "Authenticity checks",
        "role": "Reviews whether the visible image looks consistent with a normal source image.",
        "status": "completed",
        "evidence_count": 1
      }
    ]
  }
}

Redaction

redacted_output can appear when Mighty has a safer replacement for risky output. Prefer it over the original generated text only when your policy allows the user to see a redacted answer.

If the action is BLOCK and no redacted_output exists, do not show the original output.

Poll Async Result

curl https://gateway.trymighty.ai/v1/scan/$SCAN_ID \
  -H "Authorization: Bearer $MIGHTY_API_KEY"

Error Handling

See Error Handling for 400, 402, 409, 413, 429, and async states.

AI-Agent Prompt

AI-ready prompt

Use the API reference

Paste this into Cursor, Codex, Claude Code, or Windsurf.

Use the Mighty API reference to implement a server-side integration.

Endpoint:
- POST https://gateway.trymighty.ai/v1/scan
- GET https://gateway.trymighty.ai/v1/scan/{scan_id}

Rules:
- Use bearer auth from MIGHTY_API_KEY.
- Use scan_phase=input for submitted material.
- Use scan_phase=output for generated or extracted output.
- Reuse scan_group_id for related scans.
- Route ALLOW, WARN, BLOCK.
- Store scan_id, request_id, scan_group_id, and session_id.
- Handle 400, 402, 409, 413, 429, pending, complete, and failed.

Read /openapi/mighty-api.yaml before writing typed client code.

Related docs

Keep going from here

Choose Scan SettingsRead practical examples first.Error HandlingHandle common responses.Async Deep ScansPoll or handle webhooks.