A self-hosted file conversion API you run yourself
Hosted conversion APIs send every file through their infrastructure and bill per job. SnapOtter gives you the same kind of REST API, running entirely on your own servers.
What most teams do today
You wire your app to a hosted conversion API, ship files to it over the network, and pay per conversion. Every file your users touch passes through a third party, and the bill scales with usage.
Why that's a problem for sensitive files
An API in your critical path that ships user files to a vendor is a data-residency and cost problem at once. You inherit their retention terms, their uptime, and their per-job pricing, and you cannot run any of it in an air-gapped or on-prem environment.
How SnapOtter does it privately
SnapOtter exposes a documented REST API: an OpenAPI 3.1 spec at /api/v1/openapi.yaml and interactive docs at /api/docs. Authenticate with an si_ bearer key, POST a file to /api/v1/tools/{section}/{toolId}, and get a downloadUrl back for fast tools or a 202 plus live progress for long ones. It runs in CI, cron, and internal services, on your own hardware.
Self-host in one command
Process a file over the REST API
Last reviewed July 10, 2026. Commands match the current single-container image and REST API. Competitor references: CloudConvert API
Frequently asked questions
- Is the API documented?
- Yes. There is an OpenAPI 3.1 spec at /api/v1/openapi.yaml and an interactive reference at /api/docs.
- How does authentication work?
- Create an API key (prefixed si_) and send it as an Authorization: Bearer header. Keys carry scoped permissions.
- Sync or async?
- Fast tools return 200 with a downloadUrl. Long tools return 202 and stream progress over server-sent events.
More self-hosted workflows
Deploying this across a team?
Audit trails, per-tool permissions, SSO, and air-gapped deployment for regulated environments. Talk to us about running SnapOtter as shared infrastructure.