Define it once. Watch every file follow it.
Describe what should happen to a file as a handful of JSON steps. Filebot runs them on every upload and shows you exactly what happened. This page walks that loop, in order.
{ "steps": [ { "id": "verify", "use": "file/verify", "input": ":original" }, { "id": "scan", "use": "file/virusscan", "input": ":verify" }, { "id": "thumb", "use": "image/resize", "input": ":scan", "params": { "width": 512 } }, { "id": "serve", "use": "file/serve", "input": ":thumb" } ]}Write the pipeline.
A pipeline is a steps array in JSON. Each step names a processor and its input, params live on every step, and you can pin a processor version when you need it to never change. Filebot validates the whole thing as a DAG before any run starts.
Steps route by reference.
Each step's input points at a prior step's output by id (:stepId) or the original upload (:original). Those references are the routing. Each output flows into the next step's input. Forward references and cycles are rejected before a run starts.
- Reference :original or any prior :stepId
- Set params and inputs at the step or pipeline level
- Validated as a DAG. Forward refs and cycles are rejected
Real processors.
Add any of these as a use step.
- image/resizeResize images
- image/convertConvert formats
- image/compressCompress images
- document/convertConvert documents
- document/thumbsDocument thumbnails
- file/hashContent hash
- file/verifyVerify by magic bytes
- file/virusscanVirus scan
- file/serveSigned delivery URL
- s3/storeStore to S3
- cloudflare/storeStore to R2
- speech/transcribeTranscribe audio
- image/ocrExtract text
- image/describeDescribe images
Run it. See everything.
Every upload becomes a run. A run reports its own status and every step's status, outputs, errors, and timing. When a step fails, you get a machine-readable reason instead of a guess.
- Run status: queued, running, succeeded, failed, cancelled
- Per-step status, outputs, and errors
- Timing: startedAt, finishedAt, durationMs
- Per-step usage and billing events
Store and deliver, yours or ours.
Results land in Filebot-managed storage or your own S3, R2, or S3-compatible bucket. Runs can even start from a file already sitting there. Everything goes out on signed, expiring URLs with a webhook you can verify.
Keep them in Filebot
We host the results on managed storage. Set how much room you need.
Send to my own bucket
Bring your own S3, R2, or S3-compatible storage. We process and deliver. You keep custody.
Start from a file already there
A run can begin with an import instead of an upload. Point it at an object in your bucket or a URL.
s3/import · cloudflare/import · http/import
HMAC-SHA256 signatures
Each delivery carries an X-Filebot-Signature v1= header with a timestamp. You verify it against a replay window.
Delivery attempts
List every delivery attempt for a webhook. You see what was sent and when.
Webhook delivery retries
Exponential backoff up to 6 attempts, then a dead-letter. Nothing drops in silence.
Queue-level job retries
Queued processing jobs retry on their own. One brief error does not fail the run.
When it breaks, it retries.
A brief failure should not lose work. Webhook deliveries and queued jobs both retry on their own with exponential backoff. A short outage stays an outage and does not become a dropped event.
Control who does what.
Least privilege for people and programs. Every API key carries resource and action scopes, teammates hold roles, and an audit log records the changes.
- Resources: runs, pipelines, webhooks, credentials
- Actions: read, write, or * for full access
- Secrets are reveal-once and stored hashed
- SSRF guards on imports and webhook targets
{
"runs": ["read", "write"],
"webhooks": ["read"]
}Owner, admin, member
Three roles scope what each member does.
Email invitations
Invite teammates to your organization by email.
Audit log
Filebot records member and API-key changes.
See a run for yourself.
Start free and watch your first file go through, step by step.
No credit card needed.