After completing a detailed vendor evaluation of several AI video clipping tools for my team’s podcast production workflow, I selected Opus Clip for its balance of output quality and API accessibility. However, a significant bottleneck remained: the manual process of taking a finished Riverside.fm recording and getting it into Opus Clip for processing. To eliminate this friction and improve the overall Total Cost of Ownership (TCO) of our tech stack, I've engineered a Zapier automation that handles this seamlessly.
The workflow is triggered automatically upon the completion of a Riverside.fm recording, which posts the video file to a designated Google Drive folder. The automation proceeds as follows:
* **Trigger:** New file in a specific Google Drive folder (the Riverside.fm export destination).
* **Filter:** A Filter step by Zapier checks the file name for a keyword (e.g., "Podcast-Episode") to ensure only relevant recordings proceed, preventing false triggers.
* **File Transfer:** A crucial step involves using a "Transfer File" action (via the CloudPipes app on Zapier) to move the file from Google Drive directly to an Opus Clip-compatible cloud storage, specifically a Backblaze B2 bucket. This is necessary because Opus Clip's API does not accept direct Google Drive links.
* **API Call:** A Webhook action (POST request) is then sent to Opus Clip's `/v1/video` API endpoint. The payload includes the public, signed URL of the file in Backblaze B2 and the desired processing parameters (e.g., `horizontal` aspect ratio, `9` for the number of clips).
* **Notification & Logging:** Finally, a formatted notification containing the Opus Clip job ID and source file name is sent to a dedicated Slack channel for logging and monitoring. The job ID is also appended to a Google Sheet for future reference and potential reconciliation.
**Key Considerations & Pitfalls Addressed:**
* **Security & Compliance:** The Backblaze B2 bucket is configured with a limited-life, signed URL for each upload, ensuring no persistent public access. This meets our internal data handling policies for unreleased content.
* **Error Handling:** The Zap includes a path for caught errors, which routes failure alerts to a separate Slack channel with detailed error messages from each step for rapid diagnosis.
* **Cost Analysis:** While this automation adds a marginal cost for the Zapier tasks and Backblaze B2 egress, it eliminates approximately 15-20 minutes of manual effort per episode. The TCO calculation shows a clear positive return given our volume, not even accounting for the value of consistent, error-free process execution.
I am interested in hearing from others who have integrated Opus Clip into automated workflows. Specifically, have you encountered any latency issues between job submission and the availability of clips via the API, and how do you handle polling for completion? Furthermore, are there alternative, more elegant solutions to the cloud storage intermediary step I'm using with Backblaze B2?
—LJ
—LJ
Great point about using a filter step for the file name. That's a must. I've seen automations fail because a stray test file or a misnamed clip triggered the whole expensive process.
For the "Transfer File" step, have you considered using the native Google Drive to Opus Clip integration? I know Opus can pull directly from Drive links, which might eliminate the need for an extra app like CloudPipes. Might save a Zap task and some potential lag.
How reliable have you found the latency from Riverside's "recording complete" to the file actually landing in Drive? That's been a variable for us.
Your point about the native Drive integration is valid for reducing task count, but it introduces a hard dependency on Opus Clip's authentication stability, which I've found less reliable than a dedicated transfer service. Using a middleware like CloudPipes abstracts the storage layer, so if we ever switch clipping providers, only one Zap step needs reconfiguration instead of the entire file acquisition logic.
Regarding latency, Riverside's export to Drive averages 2-5 minutes post-"complete" notification for our 90-minute sessions, but the variance can spike to 15 minutes during their peak backend hours. The automation's filter step runs immediately on the Drive trigger, so the actual delay is purely in Riverside's processing queue, not the Zap. We added a 10-minute delay step before the transfer action as a cost-saving measure to avoid unnecessary Opus API calls on partially uploaded files.
Measure twice, cut once.