Integrator docs

Scan the file before your workflow funds or pays.

Citadel checks the paystub, the photo, and the text already read from them. One call returns allow, review, or block with the evidence.

See it on your filesStart in 5 minutesGet API key

Step 1

Thing

text, image, PDF, document

Step 2

Source

user submitted or system generated

Step 3

Risk

hidden instructions, steering, edits

Step 4

Route

continue, review, redact, stop

Route every scan

ALLOWcontinue

WARNreview, redact, or add friction

BLOCKstop the workflow

Use redacted output when available. Send weak or suspicious evidence to review. Citadel flags risk. Your team makes the decision.

Customer filePaystub, photo, claim packet

CitadelPOST /v1/scan

Product routeContinue, review, redact, block

Choose your integration

Start from the workflow you already have.

Use Cases

Income docs before funding. Claim photos and estimates before payout. Then the other packets.

Open guide

Choose Scan Settings

Pick settings from the file in front of you: paystub, photo, upload, extracted text, or a model summary.

Open guide

FAQ

What Citadel checks, what it does not claim, and what your app should store.

Open guide

How Citadel Works

The scan pipeline from the customer file to ALLOW, WARN, BLOCK, redaction, and review.

Open guide

Multimodal Setup

Settings for text, images, PDFs, documents, extracted text, model output, and PII.

Open guide

Chat Apps

Scan prompts before the model runs and public output before users see it.

Open guide

File Uploads

Check PDFs, invoices, estimates, and income docs before storage or automation.

Open guide

Damage Photos

Route a suspicious or indeterminate photo to review before the claim pays.

Open guide

Extracted Text

Scan text already read from the file so hidden instructions do not become fields.

Open guide

Workflow Playbooks

Where the scan goes in funding, bind, payout, and the systems around them.

Open guide

Sessions And Billing

Connect related scans with scan groups, then handle SCU, limits, 402, 413, and 429.

Open guide

Citadel checks the file a borrower or claimant sent, before your workflow funds, binds, or pays. Mighty is the company. The API host stays gateway.trymighty.ai. Keep the key in MIGHTY_API_KEY.

Citadel flags generated or edited files, and hidden instructions inside those files. It does not score whether a claim is true.

The call

Scan the file when it arrives (scan_phase=input). If your workflow later reads text out of that file, or a model writes a summary, scan that too (scan_phase=output) and reuse scan_group_id.

Reuse session_id when the same loan, claim, or chat continues. For setting recipes, start with Choose Scan Settings.

The basic call

curl -X POST https://gateway.trymighty.ai/v1/scan \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Please process this claim note before the adjuster sees it.",
    "content_type": "text",
    "scan_phase": "input",
    "mode": "secure",
    "focus": "steg",
    "profile": "balanced",
    "data_sensitivity": "standard"
  }'

Read the result

action is always one of ALLOW, WARN, or BLOCK. Marketing copy says allow, review, or block. The API names review as WARN.

The forensics block can return authenticity.verdict = "indeterminate" when evidence is weak, incomplete, or conflicting. That is a verdict on the file, not a routing action. Treat indeterminate as a review route.

What shows up in the file

• Generated or edited damage photos.
• Altered invoices or repair estimates.
• Synthetic paystubs, W-2s, or bank statements.
• Hidden instructions in PDFs, images, or text already read from the file.
• Extracted text that tells an automation to ignore rules.
• Unsafe model output before a reviewer sees it.

Citadel gives you one place to inspect that material and route it before funding, bind, or payout.

Drift

Risk changes when users submit new formats, a reader produces new text, models change output, tools return new content, or policy moves from tolerant to strict.

Rescan derived output with the same scan_group_id. Keep the wider loan, claim, batch, or agent run on the same session_id.

Give this to your AI coding agent

You are adding Citadel, Mighty's product, to an existing lending or claims workflow.

Goal:
Add a server-side scan before a customer-submitted file reaches funding, bind, payout, storage, or automation.

Use:
- API base URL: https://gateway.trymighty.ai
- Endpoint: POST /v1/scan
- Env var: MIGHTY_API_KEY
- Never expose the API key to the browser.

Read these docs first:
- /docs/quickstart
- /docs/use-cases
- /docs/concepts/how-mighty-works
- /docs/concepts/configs
- The guide that matches the file

Implementation rules:
1. Scan the submitted file with scan_phase=input.
2. Store scan_id, request_id, session_id, and scan_group_id.
3. Route ALLOW, WARN, BLOCK. Marketing calls WARN review.
4. Reuse scan_group_id when scanning extracted text or a model summary from the same file.
5. Use data_sensitivity=tolerant only when expected PII should not block the workflow.
6. Add tests for ALLOW, WARN, BLOCK, 400, 402, 413, and 429 paths.
7. Rescan derived output when the reader, model, agent, or policy changes.

Acceptance criteria:
- API key only exists on the server.
- Scan errors use safe fallback behavior.
- Logs include request_id and scan_id.
- A flagged file does not reach funding, bind, or payout without a route.
- Review wording says Citadel flagged risk, not that it proved fraud.

Production checklist

• Keep MIGHTY_API_KEY on the server.
• Generate a unique request_id per scan or let Citadel generate one.
• Persist scan_id, scan_group_id, session_id, and action.
• Route WARN to review or a constrained flow.
• Route BLOCK to a safe stop.
• Use async for deep image or PDF checks when latency matters.
• Store raw files according to your own retention policy.
• Do not tell users that Citadel proved fraud. Say it flagged risk for review.