Add Video Captions in Make.com with the ZapCap API

A captioning scenario needs to produce a usable video, keep track of work already submitted, and recover when a step fails. If you already use Make to move files between your tools, you can build that workflow around the ZapCap API.

Make offers a community ZapCap connector maintained by Codex Solutions International. Its listing identifies a separate third-party payment requirement. This guide describes the direct HTTP route instead. Compare the connector's current terms with the setup effort of maintaining your own requests; neither choice makes Make usage or ZapCap rendering free. Community connector

Start with one clip and a clear destination

Choose a short video you own and a destination for the finished file. Keep the scenario inactive while building it. Your first milestone is one reviewed export, before connecting a folder containing many client videos.

Confirm API access and available credits in your ZapCap dashboard. Also check the file-handling and usage limits of your Make plan. Keep your source identifier, video identifier and task identifier together: they describe different things and become useful when investigating an incomplete run.

Connect Make's HTTP module

Use HTTP version 4 and choose API-key authentication. Configure the credential with header placement and the parameter name x-api-key. The key value is your ZapCap API key. Keep that value in the credential connection, not in a shared scenario description or example JSON. Make credential settings

Start with GET https://api.zapcap.ai/templates. Enable response parsing and inspect the result before mapping a template identifier into the caption request. A successful template request is a useful connection check; it does not prove that a video upload or render will succeed. ZapCap quickstart

If the template request returns 403 Forbidden, check the credential’s header placement and exact parameter spelling first: x-api-key. In our connection test, a misspelled header caused this error; correcting it returned HTTP 200. A 403 can have other causes, so if these settings are correct, confirm the API key and account access before submitting a video.

Map the upload and caption request

The basic request sequence is:

Upload a video URL: POST /videos/url. JSON url contains a retrievable video URL; retain returned id.

Create captions: POST /videos/{videoId}/task. Use that video ID, a chosen templateId, language, and the intended autoApprove value. Retain taskId.

Check processing: GET /videos/{videoId}/task/{taskId}. Use the identifiers from the original submission.

All these paths use https://api.zapcap.ai. For a private file, the alternative upload is POST /videos with a multipart file field named file. Our test returned HTTP 201 with id, status: "uploaded", and storageId; the caption request separately returned HTTP 201 with taskId. API request examples

In Make, JSON requests use the JSON body setting. A data structure can help keep mapped values separate from literal JSON syntax. Multipart uploads use a file field with the file name and binary data supplied by an earlier module. These are different inputs: a filename alone is not the file's contents. Make HTTP settings

Set retention using a URL query parameter, such as ?ttl=1d, on both the upload and task-creation requests. A multipart text field named ttl does not implement the documented retention setting. Save the finished file before its retention period ends. Retention settings

Check a source URL without relying on your signed-in browser. A sharing page that displays a video is not necessarily an address from which another service can download it. In our invalid-source test, ZapCap returned HTTP 400 and Make showed DataError, with a message asking for an accessible video under the size limit. No caption task was submitted. Resolve the source problem before changing caption settings; keep a failed upload from reaching task creation.

What the test verified

We sent an eight-second synthetic clip through a temporary Make webhook, converted its base64 payload with toBinary(3.content_base64; "base64"), and mapped that binary value into HTTP’s multipart file field. A normal file-download module can supply binary data directly; it does not need that conversion. The temporary input was deleted after testing.

The Maya template produced an eight-second 720×1280 H.264/AAC MP4. The returned transcript matched “This is a caption test. One short video, one finished result.” Caption samples across the output were legible. Exactly one task was submitted, and the first manual status check found it completed. This validates the API request sequence; it does not demonstrate an unattended retry loop or delivery to your storage app.

Decide where review belongs

Automatic transcript approval allows the job to continue to rendering without a separate editorial approval step. If your delivery requires checking names or technical terms first, build the approval stage deliberately. Otherwise, a task waiting for approval can look like a stalled render.

ZapCap distinguishes processing, completion and failure states. Configure the scenario to handle those outcomes separately. A completed HTTP request is not the same as a completed video. Captioning task lifecycle

Keep submission and status checking separate. Set an attempt or time limit for checks, retain the original task ID when that limit is reached, and make the unfinished item visible for investigation. Do not make every retry create another caption task: a timeout can occur while the original task is still running.

Deliver and inspect the result

Only continue to the download stage after the task reports completion. Inspect the actual status response and map its finished-video URL into Make's download module. Our completed test returned status: "completed", downloadUrl, transcript, and transcriptApproved: true. Map Data → downloadUrl from the parsed status response, and keep that request’s original video and task IDs. Result download

Configure the download's authentication for its destination. Do not automatically attach your ZapCap API credential to an unrelated storage hostname. Then map the downloaded file into your chosen destination and retain its connection to the original source.

Watch the exported clip. Check names, timing, line wrapping and whether captions cover important content. Keep failed and completed items distinguishable so a colleague can tell which files are ready for delivery.

Before activating a recurring scenario

Try a second source file and verify that it produces a separate, correctly named output. Check what happens when the source cannot be downloaded. Recover the failed step without resubmitting successful work, and ensure the finished output cannot trigger the same input workflow again.

Once those checks pass, start at a small volume and inspect your usage alongside the delivered files. The useful outcome is a repeatable supply of approved captioned videos, not simply a scenario execution marked successful.

Open the ZapCap API dashboard to confirm your access and begin with a representative sample.