How it works
A run checks a file that is already stored in your workspace, identified by itsfile_id, so there is no upload in the request. Each result appears under forensics.<key> once that detector has reported.
1
Start a run
POST /v1/forensics returns 202 with a run_id, status: "queued" and a poll_url. Runs started at upload with enabledProducts: ["FILE_FORENSICS"] run all 19 detectors; read them with GET /v1/forensics/files/{file_id}.2
Poll
GET /v1/forensics/runs/{run_id} until status is complete or error. Web presence can take up to about 180 seconds.3
Retry if stuck
A run still
queued or running after about 6 minutes is stuck. POST /v1/forensics/runs/{run_id}/retry re-runs the same file and spec_filter under a new run_id, which is the one to poll. The original run then reports error.4
Clean up
DELETE /v1/forensics/runs/{run_id} once you have the result. The file itself is not affected.GET /v1/jobs/{job_id} and have no callback. See Async jobs for how they compare with other async work.
Endpoints
Request
spec_filter is required so that a detector added later cannot silently change what an existing integration runs.
Response
Run status
Detector status
Every detector result has astatus, and usually a one-line value. Route on each detector’s status, not the run’s: a complete run can still contain an issue.
Detectors
The MCP tool
run_file_forensics offers 17 of these: all except ai_pdf_detection and ai_office_detection. See MCP tools.
Errors
See Errors for the response format.
Related
Forensics quickstart
Run your first check end to end.
Document integrity checks
Choose detectors per document and route on the result.
Uploads
Store a file and get its
fileId.MCP tools
Run fileForensics from an AI assistant.