One Video Workflow, Three Ways In: Public API, Webhooks, and MCP

The first CaptionBolt workflow lived entirely in the browser. You uploaded a video, waited for the transcript, reviewed the captions, and exported the result.

That is still the clearest way to finish one video. It becomes less clear when the same work happens every day.

A course team may record five lessons at once. An agency may need to prepare a client's videos as soon as the source files arrive. A developer may already have an internal system that knows which recording is approved, who needs to review it, and where the finished file belongs. Copying IDs between tabs is not creative work. Neither is refreshing a status page.

We kept hearing versions of the same request: can CaptionBolt fit into the workflow we already have?

Our answer is now yes. CaptionBolt has a Public API, signed Webhooks, and a hosted remote MCP server for compatible AI assistants. They are three ways into the same product—not three new video products hiding behind technical names.

The Browser Is No Longer the Only Front Door

We did not want to build a separate "developer version" of CaptionBolt.

Projects created through the Public API use the same account, processing minutes, plan limits, caption styles, saved presets, and export permissions as projects created in the app. A project can start in an automation, pause for a person to review it in CaptionBolt, and continue through the API after the edits are saved.

That last part matters. Automation should remove repetitive coordination without quietly removing judgment.

The default integration mode is review. CaptionBolt prepares the transcript and captions, then leaves the project ready for a person. auto-export is available when a workflow genuinely does not need that stop, but it has to be chosen explicitly.

Public API: Predictable Work for Predictable Systems

The REST API is the direct option for software you control.

It can read account limits, discover caption styles and your saved presets, upload a video in resumable parts, create a caption project, check its status, request an export, and retrieve the finished result. Commands return quickly with an operation to follow instead of holding one request open while a video is processed.

We also made idempotency part of the first release. If a network request times out, your system can repeat the same intent with the same idempotency key instead of guessing whether it should create a second project. Video processing has too many long steps for "the connection closed" to mean "nothing happened."

The practical use cases are not exotic. A form submission can create a project. A content calendar can attach the resulting project ID to an existing record. A client portal can show whether a video is processing, ready for review, exporting, or completed. Your system handles the coordination; CaptionBolt handles the caption workflow.

It is still your responsibility to keep the API Key on the server, request only the scopes the integration needs, and save finished files before their access window ends. The REST API guide walks through the full upload-to-result sequence, and the live API reference contains the request and response schemas.

Webhooks: Continue When Something Actually Changes

Polling is useful while a person is waiting on one screen. It is a poor way to connect two systems for days or weeks.

Webhooks let CaptionBolt notify your HTTPS endpoint when a project is ready for review, completed, failed, or cancelled. That can move a card in an internal queue, alert the right editor, or start the next approved step without asking for status every few seconds.

The events are signed. Your receiver should verify the signature against the raw request body, reject stale timestamps, and deduplicate by event ID before doing work. Deliveries can repeat or arrive out of order, so a receiver still needs to be idempotent. When a delivery fails, CaptionBolt retries twice—after about one minute and then five minutes—before stopping automatic attempts. You can inspect recent deliveries and retry one manually after fixing the receiver.

The event contains project metadata, not the video itself. A completed event points your system back to the authenticated result endpoint, where it can request a fresh download link. That separation keeps the notification small and keeps access under the API Key's permissions.

The Webhooks guide covers event types, signature verification, retries, secret rotation, and testing an endpoint before relying on it.

MCP: Let an AI Assistant Use Tools, Not Guess at Screens

The Public API is a natural fit when a developer has already defined the sequence. MCP is useful when the next step depends on a conversation.

MCP stands for Model Context Protocol. A compatible AI assistant can connect to CaptionBolt's hosted MCP endpoint and discover a bounded set of tools: list projects, inspect account limits, find styles or presets, manage an upload session, create a project, check status, request an export, retry, cancel, and retrieve a result.

That does not mean handing an agent unlimited control.

You create a dedicated API Key in Settings → Integrations, choose the scopes it needs, and store the key in the MCP host's secret settings—not in a prompt. The host must support remote HTTP MCP with a Bearer header. OAuth-only connections are not part of this release.

Then the instruction can sound like a normal working agreement:

List the CaptionBolt projects that are ready for review. Show me the newest three, and do not export anything until I approve it.

The assistant can decide which tool to call next, but CaptionBolt still enforces the API Key scopes, current plan, project ownership, credits, and valid state transitions. If the key cannot export, a confident sentence from the model does not change that.

This is the part of MCP that interests us most. It gives an assistant a way to work with real project state instead of pretending it can understand a dashboard from a description. It also gives the product a hard boundary: the assistant can only use the tools and permissions we expose.

See the remote MCP setup guide for the endpoint, connection requirements, and a first review-before-export workflow.

Three Entrances, One Set of Rules

REST, Webhooks, and MCP solve different coordination problems:

• REST starts work and reads state from software you control.
• Webhooks tell that software when a meaningful project event occurs.
• MCP lets a compatible AI assistant choose among the same bounded tools during a conversation.

Underneath, they meet the same project and export rules.

This was an architectural choice and a product choice. A second automation-only pipeline would eventually disagree with the app about captions, credits, project ownership, review state, or exports. Instead, integrations reuse the workflow we have already spent months making more durable.

It also means integrations do not bypass CaptionBolt's product boundaries. The API works with footage you have already selected. It does not search a long recording for viral clips, automatically reframe every speaker, dub a video, translate captions, or publish to social platforms. Remote URL imports and standalone Transcript creation are also outside the first release.

Those limits are not footnotes. They are what let us expose useful automation without reopening the collection of half-related products we deliberately retired.

A Good First Automation Is Boring

The best first test is not a fully autonomous content machine. It is one real video and one repeated handoff.

For example:

1. Create a dedicated API Key with project read/write access. Add export or Webhook permissions only if the workflow needs them.
2. Upload one known video and create the project in review mode.
3. Subscribe to the ready event instead of polling continuously.
4. Open the project in CaptionBolt, correct the transcript, and save the result.
5. Request the export from your system—or ask a connected assistant to prepare the action and wait for approval.
6. Receive the completed event, fetch a fresh result link, and save the file where your workflow expects it.

Once that path is reliable, remove the manual coordination that is genuinely repetitive. Keep the review decisions that protect the words, framing, and final result.

Who We Built This For

The integration layer is for people who already know where CaptionBolt belongs in their process.

That might be a developer adding captioned video to an existing product, an agency connecting client intake to an internal review queue, a course team processing lessons in batches, or an operator who wants an AI assistant to find the right project without digging through tabs.

It is not a requirement for using CaptionBolt. If you finish one video at a time, the browser remains the simplest path. The API should not turn a short workflow into an engineering project just because an endpoint exists.

Public API, remote MCP, and Webhooks are available to Max subscribers. Start in Settings → Integrations, read the integration overview, and keep the API reference nearby while you build.

Start with one handoff. Make it dependable. Then automate the next one.