01The bottleneck
The agency ships a steady volume of short-form clips across a roster of clients, and every client has its own caption look — font, placement, color, the lot. Captioning was where consistency went to die: a manual editor step repeated per clip, per client.
Every junior editor captioned slightly differently. The same client could get three subtly off-brand looks in a week, revisions bounced back over caption styling, and the captioning step quietly consumed the most billable-but-unbillable hours in the studio.
- ·Each clip captioned by hand, per client, per editor
- ·Brand caption style re-created from memory each time
- ·Revisions bounced back over styling inconsistencies
- ·Captions sometimes overran the 9:16 safe zone
- ·One locked caption template per client brand
- ·Consistent output regardless of which editor delivers
- ·Async batch delivery wired into the delivery tool
- ·Per-client usage tracking for pass-through billing
- ·Captioning off the critical path for junior editors
02The ZapCap workflow
Captioning moved out of the editor and into the agency's delivery tool. Each client is mapped to one locked caption template, so the editor just drops clips into the client folder and the tool handles the rest.
For each clip the tool POSTs the source URL to /videos, creates a task with that client's fixed templateId, and stores the taskId against the delivery. The webhook handler verifies x-signature, dedupes on eventId, and files each finished renderUrl back into the client's delivery batch.
Deliverables ship as burned-in .mp4 (h264) by default. When a client needs captions as a separate layer, the same task requests the transparent (prores4444 / vp9 alpha) output instead.
03Technical implementation
The integration landed inside the existing delivery tool, not as a new service. Each client record gained a templateId field; dropping clips into a client folder triggers a task per clip against that client's template.
Failure handling. ZapCap is treated as a normal upstream: signed webhooks, eventId-based dedupe so retries never double-file a deliverable, and per-clip status so one failed render re-queues without holding up the rest of the batch.
- templateId per client (UUID from GET /templates) — one locked caption look per brand.
- Folder-drop trigger in the delivery tool — one ZapCap task per clip routed to the client template.
- Webhook handler · x-signature verified, eventId-deduped, renderUrl filed into the client batch.
- Dual output — burned-in .mp4 by default, transparent overlay when a client wants a separate caption layer.
- Per-client usage tag so per-minute usage maps to the client it can be passed through to.
- Per-clip retry — one failed render re-queues without holding the rest of the delivery batch.
04What changed
Captioning stopped depending on which editor did the work. The client template is the single source of truth, so every delivery looks the same regardless of who built it — and styling revisions largely went away.
Billing got simpler too. Per-minute usage is tagged per client, so captioning cost can be passed through cleanly instead of disappearing into unbillable studio hours.
- ·Each clip captioned by hand, varying by editor
- ·Off-brand styling and revision churn
- ·Captioning ate unbillable junior-editor hours
- ·Captions sometimes clipped the safe zone
- ·Captioning cost buried in studio overhead
- →One locked template per client, consistent every time
- →Same output regardless of which editor delivers
- →Captioning off the editors' critical path
- →Captions respect the 9:16 safe zone in every template
- →Per-minute usage tagged and passed through per client
05In their words
Captioning was the step where every editor did it a little differently and the client noticed. Now each client has one locked template and every delivery matches it. The captioning argument just stopped happening.