Changelog

The ffprobe job runs the way ffprobe runs on your own machine. Send a command with the media URL, optionally with extra ffprobe flags, and get back a normalized summary alongside the full structured report.

The minimal command is just the URL. Core sections and JSON output are added for you, so the response always includes the complete format, streams, and chapters even if you never pass a flag. Add flags on top when you want more, like -show_frames for per-frame detail. The ffprobe prefix itself is optional.

import { createClient } from "@rendobar/sdk";

const client = createClient({ apiKey: "rb_YOUR_KEY" });

const job = await client.jobs.create({
  type: "ffprobe",
  params: { command: "ffprobe -show_format -show_streams https://cdn.rendobar.com/assets/examples/sample.mp4" },
});

const done = await client.jobs.wait(job.id);
console.log(done.output.data.summary.kind); // "video"

The summary handles the parts of ffprobe that are awkward to read raw. Rotation comes back as 0, 90, 180, or 270 from the display matrix. Embedded cover art no longer counts as a video stream. HDR is a single boolean, variable frame rate is flagged, and the audio layout is normalized even on formats where ffprobe itself omits it. It works on video, audio, and image URLs, and summary.kind tells you which one you have.

ffprobe is available from the REST API, the dashboard playground, the SDK, the CLI (rb ffprobe), and the MCP server’s probe_media tool. Probe jobs run on their own lane and don’t count against your concurrency limit, so a batch of them dispatches at once. Full details in the ffprobe reference.

Every job kept its output for a set window after it finished, but there was no way to see when that window ended. Job responses now carry retentionExpiresAt, the exact time the stored files get deleted. Free plans keep outputs for 7 days, Pro for 30.

The date reads the same everywhere. GET /jobs/:id returns it as a Unix millisecond timestamp, the MCP get_job tool returns it as an ISO string, and the dashboard shows “Files available until” on the job detail. It is frozen when the job completes, so it always matches the moment the file is actually removed.

When that window ends, the output and everything stored with it (logs, metrics, and the preview thumbnail) are removed together. Download links are separate and short lived: they refresh every time you fetch the job, so a stale link is never a sign your file is gone. Check retentionExpiresAt for that.

Every webhook Rendobar sends is signed, but verifying one used to mean rebuilding the signed string, reading two headers, and handling secret rotation by hand. The SDK now does all of it.

verifyWebhook(body, headers, secret) from @rendobar/sdk/webhooks takes the raw request body and the incoming headers, checks the HMAC signature over the timestamped payload, and rejects stale deliveries so a captured request can’t be replayed. During a secret rotation it accepts either the current or the previous secret. It returns a boolean and pulls in no runtime dependencies, so it runs on Node, Deno, Bun, Workers, and the browser.

import { verifyWebhook } from "@rendobar/sdk/webhooks";

const ok = await verifyWebhook(rawBody, req.headers, process.env.WEBHOOK_SECRET);
if (!ok) return new Response("invalid signature", { status: 401 });

Delivery behavior is documented in full now too. A delivery that doesn’t get a 2xx within 10 seconds retries up to 5 times with exponential backoff, and an endpoint that fails 10 times in a row is disabled automatically. The event catalog, retry schedule, and rotation flow live in the webhooks guide.

A job that produced an output file larger than 100 MB used to fail right at the end, after the encode had already run, with an EXECUTION_ERROR about the upload. The output was too big for the size limit on the upload path.

The output now goes straight to object storage instead of through that path, so size is no longer the bottleneck. Large transcodes, long renders, and high-bitrate exports finish and return a downloadable URL like any other job. Smaller outputs are unaffected and take the same fast route as before.

Previewing a large video output used to mean waiting for the whole file to download before it would play. The output download endpoint now answers HTTP range requests, so a player fetches only the bytes it needs. Playback starts right away and you can seek anywhere in the timeline without pulling down the rest.

This is a serving change only. The file is byte-for-byte what your job produced, with no re-encode and no extra processing. Every output format that a browser can play benefits, and existing download links keep working unchanged.

Submitting more jobs than your plan’s concurrency used to return 429 Concurrent job limit reached, so you had to poll and resubmit. Now every job is accepted. Jobs beyond your running slots wait in a queue and start automatically, oldest first, as the ones ahead of them finish.

Your plan’s concurrency is now a throughput setting, not a submission cap. Free runs one job at a time, Pro runs twenty, and either plan can hold a large backlog of queued work. A submit is only rejected when your balance is zero (402 INSUFFICIENT_CREDITS) or the queue is genuinely full (429 QUEUE_FULL, well above normal use).

Queued jobs show as waiting on the API and as a “Queued” state in the dashboard, then move to running on their own. No client changes are needed. If you were catching the concurrency 429 and backing off, you can drop that retry loop.

The Jobs page in the dashboard is rebuilt as a data table. Sort by created time, duration, or cost. Filter by status, type, client, or date range, and search across your jobs. Select multiple rows to cancel, retry, or export them to CSV.

Opening a job slides in a detail panel with two tabs. Output shows the result with an inline player and a download, plus what the run cost. Details holds the full request payload as formatted JSON, a lifecycle timeline, the inputs, machine metrics, attribution, and raw logs.

• Sort, filter, and search your full job history, with bulk cancel, retry, and CSV export.
• A two-tab job detail: Output for the result and cost, Details for the payload, timeline, machine metrics, and logs.
• The Jobs API added sort, order, and from and to date-range query parameters.

Jobs now record the client that submitted them. When you have traffic arriving from several places at once (the dashboard, the SDK in your backend, an MCP agent, an n8n workflow, the CLI, or direct API calls), you can now see how usage splits across them instead of guessing.

The Usage page in the dashboard has a new “Usage by client” panel that breaks down job count and spend per client over the selected period. There’s also a new API endpoint for pulling the same data programmatically.

• New endpoint: GET /billing/usage-by-client returns job count and amount charged grouped by originating client.
• New SDK method: client.billing.usageByClient({ days }).
• The dashboard, SDK, CLI, and n8n node identify themselves automatically. Direct API calls are attributed as api, and you can label your own integration by sending an X-Rendobar-Client header.

Attribution is best-effort telemetry for analytics. It never affects auth, routing, or billing.

If a runner accepted a job but never started executing it (a capacity problem on the execution backend), the job used to sit in a non-terminal state with no timeout. It could hang for a long time, and jobs.wait() would block until your own deadline. Now a job that has not started after its dispatch window is failed with a RUNNER_TIMEOUT error, so you get a terminal result in minutes and can retry.

Auth errors got more honest. An API key that is rejected because it is invalid, expired, or disabled now says exactly that, instead of the generic “provide a session cookie or API key” message that read like a missing header. Per-minute request limits were also raised.

The SDK jobs.wait() is steadier on long jobs:

• Polling backs off from 2s up to 10s instead of calling the API every 2s.
• A timeout throws a typed WaitTimeoutError that names the last status, so you can tell whether the job was still queued.
• Opt into throwOnFailure to have wait() throw a JobFailedError on a failed or cancelled job instead of returning it.

captions.animate now reads the way short-form creators caption. The default groups speech into a two-line phrase of four to six words at a steady size, so a viewer can scan ahead instead of catching one word at a time. Want the punchy word-by-word style instead? Set layout to word.

Placement holds steady. Captions sit at lower-center and a one-line and a two-line caption share the same center, so the block no longer jumps as the word count changes. Move it with position set to top, center, or bottom.

The active word can do more than change color. Set highlight.mode to box for a rounded pill that follows the spoken word, and pick an entrance so each word reveals as it is said: fade, pop, or a springy bounce.

All of it is one style object: layout, position, font, colors, stroke, highlight, and entrance. Start from a preset and override only what you want, or build your own look from scratch. See the captions.animate reference.

The Machine panel on the job detail page got a redesign. Each metric is now a card with the current value, a filled trend line, and the peak and average for the run. CPU, memory, and the network card shift from green to amber to red as they near their limits, so a hot job is obvious at a glance.

While a job runs, a Speed card shows how fast it is encoding relative to real time, along with the current frames per second. A job encoding at 2.3 times real time shows as 2.3x. The panel also flags when a run peaked well under its allotted CPU, so you know you can move it to a smaller machine next time.

• CPU, RAM, and Speed each show value, trend, peak, and average.
• The network card shows download and upload together, plus the total moved over the run.
• A live or final badge shows elapsed time, and cost once the job settles.
• The playground console footer carries the same numbers, now with status colors.

captions.animate got a pass on how the words move. The active-word highlight is now a clear colour change instead of a size pop. Scaling the active word made the rest of the line shift left and right as the highlight moved, which read as a jitter. Colour-led highlighting keeps every word in place, so the caption sits still and the eye follows the colour.

The gold preset’s active colour was too close to white to see. It now flips to a vivid gold, and the text is larger, so you can tell which word is being spoken. Each caption block also fades in and out instead of hard-cutting.

Timing is steadier too. Word boundaries are snapped to the video’s frame grid so the highlight lands on a frame instead of between two, and the highlight fires a touch before each word to track the voice rather than trail it. A bad final word timestamp that could freeze the highlight is now clamped.

See the captions.animate reference.

captions.animate went from four presets to eleven. Alongside hormozi, mrbeast, tiktok, and pill you now get karaoke, word-pop, minimal, subtitle-block, neon, gold, and reveal. Pick a preset, place the captions at the top, center, or bottom, and override the font, colours, stroke, and active-word highlight with a style object when you want something of your own.

Set captionData: true to also get the data back, not just the burned video. The response carries the word-level transcript with accurate timings plus standard SRT and VTT built from the same cues that were rendered, on output.data. So one call gives you the captioned video and a transcript you can reuse.

Two opt-in helpers run in our own stack at no extra cost. autoEmphasis marks the important words and paints them in the preset’s accent colour, the look creators use to make key words pop. translateTo translates the captions into Spanish, French, German, Portuguese, Italian, or Dutch before they animate. Both fall back to plain captions if they can’t run, so a job never fails over them.

You can also bring your own transcript. Pass an SRT or VTT URL and Rendobar animates your timing instead of transcribing, and pass a font URL with style.font set to its family name to render captions in your brand font.

All of it is in the dashboard playground and the captions.animate reference.

The ffmpeg job type now runs on CPU-powered or GPU-powered machines. A new optional compute param picks the hardware. It defaults to auto, so a command that uses an NVENC or CUDA encoder routes to a GPU on its own. Nothing in your existing jobs changes.

Rendobar’s FFmpeg API runs h264_nvenc, hevc_nvenc and av1_nvenc on NVIDIA L4 GPUs. Billing is per second of processing. There are no instances to start or manage.

• compute: "auto" (the default) sends NVENC and CUDA commands to a GPU and everything else to a CPU machine.
• compute: "gpu" forces a GPU. compute: "cpu" forces a CPU and rejects an NVENC command early with a clear error.
• Swap one flag to try it. -c:v libx264 becomes -c:v h264_nvenc in the same command you already send.
• GPU acceleration is available on the Pro plan. CPU and auto work on every plan.

See the FFmpeg reference for the compute param and examples.

Every job now shows what its machine is doing while it runs. The job detail page has a Machine panel with live CPU, memory, and network usage that updates once a second. After a job finishes, the same graph replays from a saved series, so you can see how a run behaved after the fact.

The numbers are on the API too. GET /jobs/:id/metrics returns the recorded series for a job, and the same samples stream live over the realtime WebSocket as job.metrics events. The SDK exposes them through onMetrics, so an agent can watch a run the way the dashboard does.

• CPU shows as a percent of the machine and as cores in use, like 5.5 of 8 cores.
• Memory is the container’s RAM, measured against its limit.
• Network shows download and upload throughput each second.
• The playground console has a compact live strip with the same numbers while a job runs.

captions.animate used to reject any input longer than 5 minutes. That cap is gone. The real limit was always your plan’s job time budget, and now that is the only bound. You can caption a video as long as it transcribes within that budget, and a clip too long for your plan times out like any other job.

Pro plans get a larger time budget than Free, so they caption proportionally longer videos.

You can now upload your own files to Rendobar instead of hosting them somewhere public first. Upload from the dashboard, the SDK (uploads.create), the API (POST /assets), or the CLI, then reference the file by its content URL in any job input.

Uploads go straight to storage over presigned URLs, so large files never pass through the API. Per-file size limits follow your plan: up to 500 MB on Free and 10 GB on Pro. Uploaded files are private to your organization and an uploaded file with the same contents is reused instead of stored twice.

Jobs now report complete the moment processing finishes. Before, the result waited on cost settlement before the job flipped to complete, which added several seconds of dead time at the end of every job. Completion and billing are now separate: you get the output right away, and the cost settles in the background a moment later.

The billing activity feed also lists job charges now. Each charge is labeled by job type and links to the job, alongside your credits, grants, and refunds.

• Job completion no longer waits on cost settlement, so results are typically several seconds faster.
• The billing activity feed itemizes job charges by type.

The FFmpeg API now handles commands that produce more than one file. Run an HLS or DASH ladder, or write an image sequence, and the job returns a playable URL plus the full file list, each at its own link. The stream plays as-is. No zip to unpack, no rehosting.

Inputs got more flexible. Alongside a URL, you can pass a file’s contents inline, which is handy for an SRT subtitle, a concat list, or a .cube LUT with nothing to host. You can also point at a file you already uploaded. Files land in the working directory under the exact name your command uses, so subtitles=subs.srt and lut3d=look.cube work the way they do on your own machine.

When a command fails, the job now returns the actual ffmpeg error output instead of a status code alone, so you can see what went wrong and fix the command.

• Multi-file outputs (HLS, DASH, -f segment, image sequences) return a playable URL plus the full file list.
• Inputs accept a URL, inline text, or a reference to an uploaded file.
• Failed jobs include the real ffmpeg error output.
• The SDK returns the typed output shape, with outputUrl() and jobData() helpers for the headline file and structured results.

See the FFmpeg job reference for the full input and output shapes.

We audited what the API returns and tightened it so responses carry only the data a client actually needs.

Jobs return a signed download URL and output metadata. Usage reporting shows what you were charged. The rest stays where it belongs.

The job type for custom FFmpeg commands is now ffmpeg, renamed from raw.ffmpeg. Shorter, and it says exactly what it does.

• Existing code keeps working. The API still accepts raw.ffmpeg and resolves it to ffmpeg, so you can migrate on your own schedule.
• The SDK exports FfmpegParams (renamed from RawFfmpegParams).
• New examples, docs, and the CLI all use ffmpeg.

See the FFmpeg reference for parameters and examples.

caption.burn is live. Pass an SRT, VTT, or ASS file and Rendobar burns styled subtitles directly into the video. Skip the subtitle file and it auto-transcribes the audio first, then burns the result.

• Language is auto-detected, so multilingual sources work without a flag.
• Font, size, weight, position, and wrapping are pixel-matched to the layout you request. Custom fonts load through a fonts directory.
• Shares the same caption engine as captions.animate, so styling stays consistent across both job types.

See the caption.burn reference for parameters and presets.

The active word in captions.animate could drift ahead of the audio on longer clips. We reworked the timing so each word is aligned to the speech it belongs to.

The highlighted word now lands on the spoken word across the whole clip, including fast passages where the old timing slipped. No parameter changes are needed. Resubmit a job to pick up the tighter sync.

The dashboard now has a full API keys page. Create, name, and retire keys without leaving the browser.

• Set an expiry date per key.
• A status pill shows active, expired, or disabled at a glance.
• Rename or disable a key in place.
• The secret is revealed once on creation, with an inline test to confirm it works.

Open app.rendobar.com and head to settings to manage keys.

@rendobar/[email protected] is on npm. It covers every live job type, realtime job progress over WebSocket, and webhook signature verification out of the box.

• Typed helpers for each job type, validated before the request leaves your process.
• Realtime job updates without polling.
• verifyWebhook() for HMAC-signed delivery checks.

Breaking: the 2.x client reshapes a few response types from 1.x. See the SDK changelog for the upgrade notes.

Rendobar documentation is live at rendobar.com/docs.

• ffmpeg reference with parameters, response shape, and plan caps.
• A webhooks guide covering HMAC signature verification.
• MCP integration docs for connecting agents.

The site runs on Mintlify with an interactive API playground.

Rendobar is now publicly available. Process media with a single API call.

Live at launch

• FFmpeg execution. Bring your own FFmpeg command and run it in a sandboxed cloud environment.
• Credit-based billing. Pay for what you use. The free tier includes a signup grant with no credit card.
• Realtime updates. Track job status live in the dashboard and over WebSocket.
• MCP tools. Six built-in tools connect Rendobar to Claude, GPT, and other agents.
• Webhooks. Signed delivery for job completion events, with HMAC verification.

API

• REST API documented with an OpenAPI 3.1 spec.
• OAuth login with GitHub and Google, plus API key auth.
• Organization-based multi-tenancy with team management.