Build file-processing workflows visually, then turn them into production-ready API requests.
Pipeline progress
0%
step
01 / 04
POST /uploads · Receive source file
POST /conversions · Target format
options.quality · Keep detail, reduce size
GET outputUrl · Signed download link
Every request on the right is generated live from the steps on the left. The API converts one file per request, so each processing step re-uploads the previous output rather than pretending a server-side job exists.
The upload returns file.fileId. The name, size and format above are the fields POST /conversions expects alongside it.
{ "baseUrl": "https://api.orbconvert.com/api", "auth": { "header": "x-api-key", "value": "<YOUR_API_KEY>" }, "source": { "fileName": "sample.docx", "fromFormat": "docx", "fileSize": 248832 }, "requests": [ { "step": 1, "name": "Upload the source file", "method": "POST", "url": "https://api.orbconvert.com/api/uploads", "contentType": "multipart/form-data", "fields": { "file": "sample.docx" }, "returns": "{ file: { fileId, originalName, mimeType, size, format, category, path } }" }, { "step": 2, "name": "Convert sample.docx -> pdf", "method": "POST", "url": "https://api.orbconvert.com/api/conversions", "body": { "fileId": "<fileId from step 1>", "toFormat": "pdf", "fileName": "sample.docx", "fileSize": 248832, "fromFormat": "docx" }, "returns": "{ conversionId }" }, { "step": 3, "name": "Wait for the conversion", "method": "GET", "url": "https://api.orbconvert.com/api/conversions/:conversionId", "poll": "Repeat roughly every 2s until conversion.status is \"completed\" (or \"failed\").", "returns": "{ conversion: { status, progress, outputUrl, outputSize, error } }" }, { "step": 4, "name": "Download the final result", "method": "GET", "url": "conversion.outputUrl", "note": "Signed, short-lived, owner-bound download link." } ] }
The builder is a front-end for the conversion API. It never invents an endpoint to make a workflow look simpler than it is.
The page starts from Configure File Input → Processing Task → Export Result. Add as many processing steps as the pipeline needs, and reorder, duplicate, or delete them freely.
JSON, cURL, Node.js and Python are rebuilt from the live step state. Change a target format or an option and every snippet updates with it.
POST /conversions queues a single conversion and returns a conversionId. Poll GET /conversions/:id until status is completed, then read outputUrl.
There is no server-side chaining and no dependency graph. To feed one step into the next, download conversion.outputUrl and re-upload those bytes to POST /uploads for a new fileId.
Grab the generated snippet in your language of choice, drop it into your codebase, replace the placeholder API key, and ship. The output is production-ready — no boilerplate to clean up.
The endpoints the builder can generate requests for, and the option keys the server actually accepts.
x-api-key: YOUR_API_KEY
Authorization: Bearer YOUR_JWT
x-guest-fingerprint: <uuid> (optional)
API keys are sent in the x-api-key header. A JSON Web Token from POST /api/auth/login is sent as Authorization: Bearer. Create and revoke keys through /api/api-keys.
In this codebase a “job” is a single conversion record. Conversions are not chained on the server and there is no dependency graph, so a multi-step workflow is upload → convert → poll → download → re-upload → convert → poll → download, driven by the caller. The generated snippets show exactly that sequence.
Upload a source file (multipart field file). Returns file.fileId plus the detected format and category.
Import a remote file from a URL.
Import a file from a connected cloud provider.
Start a conversion. Body: fileId, toFormat, fileName, fileSize, fromFormat, options. Returns { conversionId }.
Poll a conversion. Returns { conversion: { status, progress, outputUrl, outputSize, error } }.
Run one conversion across many files. Body: { files: [{ fileId, fileName, fileSize, fromFormat, options? }], toFormat, options }.
Download a converted file using its signed, short-lived URL.
List the tool catalogue; GET /api/tools/:slug returns a single tool.
Exchange credentials for a JWT.
List, create and revoke API keys (requires a signed-in user).
image
quality, maxWidth, maxHeight, fit, progressive, stripMetadata, targetSizeKb, lossless
video
resolution (720p | 1080p), codec (h264), crf, bitrate, framerate (24 | 30), audioBitrate, stripAudio
audio
bitrate, sampleRate, channels, normalize
document
metadata (remove | keep) — the only one accepted
vector
density
archive
compression
ebook · cad
ebook: none · cad: density
Options are validated against the targetformat’s category. Any other key returns HTTP 400 (UNKNOWN_OPTION or OPTION_NOT_APPLICABLE).
There is no merge route in the API.
There is no split route in the API.
No watermark implementation exists in the backend.
No thumbnail implementation exists in the backend.
These appear in the Add Step menu as disabled entries. They are not working operations and the builder will not generate requests for them.
Design your file-processing pipeline in the visual builder, then copy the generated code into your application. No SDK lock-in, no hidden abstractions — just raw HTTP calls to the same REST API your code will ship with.
File uploads and URL import.
Create, poll, and retrieve — from fileId to outputUrl.
Every validated option key grouped by target category.
API keys, JWTs, and guest fingerprints.
The builder is a thin layer over the same conversion endpoints the rest of the platform uses — nothing more.
Every snippet is produced from the steps you configure, and only references endpoints that exist in the API.
API-key examples send x-api-key; token examples send Authorization: Bearer — matching the server's auth middleware.
The controls match the option keys the server accepts for the chosen target's category, so the builder cannot produce a 400 by design.
Multi-step workflows are expressed as upload, convert, poll, download and re-upload, because the API has no server-side job chaining.
