Video Editing API

See the Tool Registry Before You Commit

108 tools, published and documented. 50 free credits on signup, no card.

The Three Architectures

Everything sold as a video editing API is one of three shapes. The difference is not the feature list. It is who composes the specification, and whether anything in the system ever looks at your footage.

The row that decides most evaluations is deterministic. A template renderer and an ffmpeg pipeline are pure functions: same input, same bytes, testable in CI. An agent is not, because a model chooses the cut points. If you need reproducibility, stop reading and buy a renderer — that is not a limitation you can work around, it is the definition of the thing.

The Incumbents, Described Fairly

Three products own the term "video editing API" and deserve to. All three are real, documented, asynchronous JSON render services with published pricing. Facts below were read from each vendor's own documentation and pricing pages on 5 August 2026.

Shotstack is the most editor-shaped of the three. Its Edit JSON is a real timeline — an array of tracks, each holding clips, each clip wrapping an asset, positioned by start and length, with a soundtrack alongside and an output block for format and size. The asset catalogue is wide: video, image, audio, text, title, HTML, luma-matte and chromakey assets, rich captions with word-level animation, and generative text-to-image, image-to-video and text-to-speech assets. You POST that to https://api.shotstack.io/edit/v1/render with an x-api-key header, and either poll the render id or register a callback URL. Alongside the Edit API it publishes an Ingest API and a Serve API, plus a Studio SDK for embedding editing into your own app, so it is closer to a platform than an endpoint.

Creatomate optimises for the case where a non-developer designs the video and a developer only supplies the data. You build a template in its visual editor, then POST a template_id and a modifications object to https://api.creatomate.com/v2/renders under an Authorization: Bearer header, overriding text, colours and media URLs by element name — dot notation reaches individual properties, and an empty object removes an element outright. It leans hard on no-code distribution — CSV bulk import, Zapier and Make — which is the correct instinct for marketing automation and a genuine differentiator against the more code-first alternatives.

JSON2Video models a video as scenes containing elements and takes it at POST https://api.json2video.com/v2/movies behind an x-api-key header, returning a project id you poll on GET /v2/movies. Voiceover (Azure and ElevenLabs text-to-speech), automatic subtitles and scene transitions are all handled server-side, and it distributes through Make, Zapier, n8n and Node/PHP SDKs.

Worth being blunt about one thing, because it undercuts the obvious pitch: having an MCP server is not the difference. Shotstack ships a native one, and it is not a lesser integration than Valmera's — its own docs give both a remote streamable-HTTP endpoint at https://mcp.shotstack.io/ behind OAuth and a local stdio build you run with npx -y @shotstack/shotstack-mcp-server and a SHOTSTACK_API_KEY. Creatomate and JSON2Video publish no MCP server of their own as of 5 August 2026, though third-party community servers for JSON2Video exist on npm. What differs is what the tools reach. Shotstack's compose a render specification out of assets you name — the same job its REST endpoint does, with a model typing the JSON instead of you. That is still an agent writing a spec for supplied assets, not an agent watching a recording you made. Valmera's tools reach an editor that has already indexed your footage, so they take instructions about content the model has seen rather than parameters it was handed. That is the whole distinction; the transport is not.

When a Template Renderer Is the Right Answer

Most of the time. If you can write the edit down before you have seen the footage, a template encodes it and a renderer executes it faster and cheaper than any agent will. The canonical cases are all volume cases: personalised video ads keyed off a customer record, property listings assembled from photos and a price, sports highlight cards generated from a stats feed, e-commerce product videos generated per SKU, weekly reports rendered from a dashboard, localised variants of a single creative across forty markets. In every one of those, the creative decision was made once by a human and the API's job is faithful repetition — exactly what a per-render-minute cost model is designed for, and exactly what an A/B test across hundreds of variants needs.

It stops working the moment the interesting decision lives inside the footage. A template cannot know that the second take was the good one, that the guest talked over the host for eleven seconds, that the answer worth clipping starts mid-sentence four minutes before the question you searched for, or that the speaker drifted out of frame and the crop needs to follow them. Those are not parameters. They are judgements about specific material, and the only way to make them is to read the material — which is what the third architecture is for.

What Valmera Publishes Instead

Valmera is an agentic video editor. Its programmatic surface is a remote Model Context Protocol server at https://entrepreneur-bot-backend.onrender.com/mcp, served over streamable HTTP with OAuth 2.1, dynamic client registration and PKCE — so in a client that speaks OAuth the client registers itself, the user signs in, and there is no token to copy or key to rotate. Point any compliant MCP client at it: the Claude app as a connector, Claude Code with a bearer token, or your own. The setup guide covers the first two.

What the server exposes is 108 tools — 97 editing tools plus 11 session tools for projects, uploads, indexing, rendering, export and download. Critically, these are not re-declared for MCP. The editing engine publishes one registry and the connector serves it verbatim, so a model in your session receives exactly what Valmera's in-house agent receives: same names, same schemas, same refusals. There is no second tool list that can drift out of date with the first, which is the failure mode of every product that bolts an agent interface onto an existing API after the fact.

The tools write to an edit decision list (EDL), never to pixels. That is what makes every operation reversible, keeps your original upload untouched, and lets the final export come from the original file at source quality while previews render from a fast proxy. Uploads are accepted up to 14 GB or 3 hours in MP4, MOV, MKV or WebM — a hard, checkable ceiling that is worth demanding of anything you integrate, because almost nothing in this category publishes one.

The Call Shape: Fast Tools and Job Ids

Two things behave differently, and knowing which is which is most of what integrating against this feels like. Tools that only rewrite the decision list answer inline in one round trip. Tools that have to move pixels — preview renders, final exports, region repainting — hand back a job id, and you call wait_for_job. Nothing fabricates a completion it has not got.

A Worked Example

Take one concrete job: an 80-minute two-person podcast recording that needs the dead air and filler words gone, captions burned in, music underneath, and a vertical cut for Shorts. Here is what that looks like in each architecture.

As a render API call

Faithful to Shotstack's published Edit schema, trimmed for length:

POST https://api.shotstack.io/edit/v1/render
x-api-key: <your key>

{
  "timeline": {
    "tracks": [{
      "clips": [
        { "asset": { "type": "video", "src": ".../ep114.mp4" },
          "start": 0,    "length": 41.8, "trim": 12.4 },
        { "asset": { "type": "video", "src": ".../ep114.mp4" },
          "start": 41.8, "length": 63.1, "trim": 58.9 }
      ]
    }]
  },
  "output": { "format": "mp4",
              "size": { "width": 1080, "height": 1920 } }
}

The API will render that perfectly. The problem is every number in it. Where does 12.4 come from? You ran ASR, or a silence detector, or a shot detector, and wrote the code that turned its output into trim points and lengths — for all several hundred cuts an 80-minute recording produces. The renderer executed your decisions; it did not make any. That work is the actual job, and it is the part the API does not do.

As an MCP session

Same job, driven by a model holding Valmera's registry. Tool names are the live ones; parameters are on the tool reference.

create_project            → project id
upload_start / upload_finish
index_status              → word-level transcript + speaker
                            labels, silences, shot boundaries,
                            labeled frame tiles          [once]

cut_silences              → dead air gone, snapped to words
remove_filler_words       → um, uh, er, hmm
add_captions              → burned in, timed to the NEW edit
add_music / set_music_fit → ducked under speech
auto_reframe              → 9:16, crop aimed at the speaker

render_preview            → { job_id }
wait_for_job              → preview ready
look_at(output_times=[…]) → the agent inspects its own frames

export_final              → { job_id }
wait_for_job → download_url
                          → MP4 from the ORIGINAL file

Note what is absent. No timestamps. Nothing in that session computed a trim point, because the index already holds word-level timestamps with speaker labels, every measured silence, and shot boundaries — produced once at upload and reused by every request afterwards. That is why a request against a three-hour file is not three hours of work, and it is the reason the ordering matters: captions are timed against the edited program rather than the raw stringout, and the music is fitted to a length nothing knew until the cuts landed.

The look_at call is the part with no equivalent in a render API. The agent is handed real frames out of the preview it just produced and reads them, so a caption sitting over a face gets caught and re-aimed before you ever see it. A renderer cannot do this, not because it is worse software but because nothing in its architecture is capable of having an opinion about its own output.

How to Edit Video Programmatically with Valmera

1. 1
   Connect an MCP client

   Add https://entrepreneur-bot-backend.onrender.com/mcp as a connector in the Claude app, attach it to Claude Code with a bearer token, or point your own MCP client at it. Auth is OAuth 2.1 with dynamic client registration and PKCE, so a client that speaks OAuth registers itself and you simply sign in.
2. 2
   Create a project and upload the footage

   create_project, then upload_start and upload_finish. Up to 14 GB or 3 hours per video in MP4, MOV, MKV or WebM. Poll index_status until indexing completes — a word-level transcript with speaker labels, detected silences, shot boundaries and labeled frame tiles. This cost is paid once and reused by every later call.
3. 3
   Call editing tools, then wait on the render

   Editing tools rewrite the edit decision list and answer inline. render_preview and export_final return a job id — call wait_for_job, then download_url. The export renders from your original file at source quality; the preview came from a proxy.

Indexing dominates the first call on a long upload and reports progress throughout. Every request after it reads the index, so the second edit on a three-hour file is not slower than the second edit on a three-minute one.

What This Is Not — Eight Specific Limits

A tool that will not name its edges is asking you to find them in production. Here are Valmera's, stated as a developer would need them stated.

Feature-level gaps are on the tool reference in full, but the short list: no whole-video text-to-video generation, no true crossfade or dissolve, no per-cut transition choice, no motion-tracked overlays, no custom font uploads, no multi-cam sync, no audio denoise or per-speaker levelling, no AI music generation, and no direct publishing to YouTube or TikTok. English is the best-tested transcription path. The agent refuses out-of-scope requests rather than faking them — every reply is verified server-side against the edit decisions actually recorded, so it cannot report an edit it did not make.

How to Choose

One question separates these cleanly: can you write the edit down before you see the footage?

• Yes, and I need thousands of them. Template renderer. Shotstack if you want a real timeline model and a platform around it; Creatomate if a designer owns the template and you only supply data; JSON2Video if scene-and-element JSON with built-in voiceover fits your content. Per-minute metering is the right cost model and you should not fight it.
• Yes, and I want to own the stack. ffmpeg, or MoviePy, Remotion or Editly over it. Cheapest at volume, unlimited in what it can express, and you carry the timeline logic, the ASR and the render capacity. For a rule-based pipeline in a team that already runs ffmpeg, this usually wins.
• No — the decisions are in the recording. An agentic registry. The work is watching the footage and choosing, and no specification you write in advance contains that. This is talking-head video, podcasts, screen recordings, course modules, interviews and social cutdowns from real material.
• No, and I need frame-level authority over the result. A traditional NLE — Premiere, DaVinci Resolve, Final Cut. Multi-cam sync, node-based colour, keyframed compositing and motion tracking are all things an agent does not do and a template cannot express.

A note on the category's direction. In "It's time for agentic video editing" (Justine Moore, a16z, 21 January 2026), the work a video agent takes on is split into five parts — Process, Orchestrate, Polish, Adapt and Optimize. Only Orchestrate, coordinating several models into one output, is something a render API can serve today; the other four require reading the material. That is the structural reason these architectures are converging on the agentic end rather than the templating end, and the reason incumbents are adding agent interfaces on top of their render endpoints rather than the reverse.

Using Both

These are not mutually exclusive and the split is often obvious. A media team with a weekly show and a performance-marketing function typically wants both: a renderer generating hundreds of ad variants from a spreadsheet on autopilot, and an agent cutting the actual episode where the judgement lives. They meet at the file — Valmera exports H.264 MP4 you download, and a renderer takes URLs, so the output of one is a valid input to the other.

What does not compose is project state. There is no EDL, XML or AAF interchange in either direction, and captions are burned into the picture rather than delivered as a sidecar file, so a B-roll pass or an aspect ratio variant done in one tool cannot be re-opened in the other. Plan the handoff at the rendered file, not at the timeline.

Frequently Asked Questions

Drive It From Your Own Client

108 tools over MCP, OAuth 2.1, no key to store. 50 free credits on signup, no card required.