Skip to content
VIDMOATDocs

Vidmoat developer documentation

The engine behind the Vidmoat editor, as 36 REST endpoints, an MCP server, signed webhooks and Telegram bots. Create a project, apply edit commands, render it, read the result.

Vidmoat is a hosted video editor. Everything a person can do on its timeline, your code can do too: the API runs every edit through the same command reducer the editor uses, so there is no second definition of what an edit means. A command that works today keeps working.

The base URL is https://api.vidmoat.com/v1. Requests and responses are JSON, except media upload (multipart) and preview frames (JPEG). Every request carries Authorization: Bearer <token>.

QuickstartA first render in five minutes, with a free test key.API referenceEvery endpoint, with parameters, examples in curl, Node and Python, and the response.MCP serverConnect Claude, ChatGPT or Cursor and let an agent edit on a real timeline.Telegram botsConnect your own bot. Your users edit video in chat, billed to your app.

How it fits together#

  1. Mint a key in the console. Test keys are free on every plan.
  2. Create a project with POST /v1/projects. A project is one timeline document.
  3. Edit it with commands through POST /v1/projects/{id}/commands: add clips, text, captions, effects, keyframes.
  4. Look before you render. GET /v1/projects/{id}/preview returns layout lint and exact frames, for free.
  5. Render with POST /v1/renders, then wait for the render.completed webhook or poll the job.
Projects and commandsThe document, the reducer, and why every edit is a command.Renders and previewsJobs, statuses, frames and when to use which.Credits and plansWhat costs credits, what uses quota, and what is free.Test and live keysWhat a test key really does, and what it does not fake.WebhooksSigned events, verification in Node and Python, retries.Errors and retriesStable error codes and what is safe to retry.

What is deliberately not in the API#

Only the documented v1 routes are a supported public contract. Internal routes carry no versioning promise. These are the ones people ask about:

  • Browser recorder. Holds a CPU core for about three minutes on the machine that serves the API. Per-app allowlist only.
  • Inpainting. One global CPU worker capped at 1/user, a single API caller would starve everyone else.
  • Flows. An orchestration product built on these primitives, not a primitive itself.
  • Vidmoat Social. Posting to a public feed as a third party is a moderation liability with no revenue. No scope grants it, and none will.
  • Channels, CDS, admin, billing. Internal surfaces with no versioning promise. They will be refactored without notice.

Versioning#

Additive changes ship into v1: new fields, new endpoints, new enum values. Ignore unknown fields; a client that rejects them can break on a routine release. The Vidmoat-Version request header defaults to 2026-08-01 and is echoed back on every response. It is reserved for future versioning and does not select different behaviour today. Changes are listed in the changelog.

For agents and assistants#

Every page has a Markdown twin: add .md to its URL. /llms.txt is the index and /llms-full.txt is the whole documentation in one file.