Automating Vimeo OTT Video Transfer with Make.com and AI

Back in a previous post, I wrote about a prototype I had built in my own time. It was a no-code workflow using Make.com and AI assistance to automate video and metadata transfer between two platforms, solving a problem that had previously only been quoted for as expensive custom development.

The prototype worked, but getting something to work in a couple of evenings is very different from turning it into a production system.

The client behind the original problem was the European Film Awards, which used Nucleus to manage its awards entries and Vimeo OTT for its membership viewing platform. I had built the prototype independently and on my own initiative. Once it worked, I took it back to BAFTA and asked whether I could propose it properly to the client. We now had a workflow that could be implemented without funding a full bespoke integration build, along with a much clearer idea of the work involved. This resulted in a dramatically reduced implementation cost for the client.

I realised fairly quickly that webhooks would be needed to build a better version of the workflow. This would also improve the wider Nucleus Automations project and make future integrations easier. There had been other integration requests over the years, but clients had always baulked at the cost. If Nucleus had webhooks, we could use Make.com to connect it to thousands of other products.

In practice, the same webhook could be reused as the trigger mechanism, although each award cycle or process still needed its own automation copied from a base workflow. The 38th EFA Awards, the 39th EFA Awards and the Short Films award would each have their own scenario.

The client was keen to review the process once they heard we had potentially solved the problem. They appreciated that we had gone back to something long after it had first been raised rather than simply leaving it unresolved. They signed off the proposed approach and I ran scoping sessions with them to understand the full workflow, as the prototype had only been built from my memory of the original issue.

At the same time, I worked to define the webhook functionality so it could be released soon after the rest of the Nucleus Automations project. The webhooks were designed to send three identifiers, Entry ID, Award ID and Entity, which in this case would be Entry. The webhook itself would not contain the full entry data. Make.com would use those identifiers to retrieve the information through the authenticated Nucleus API, preserving the existing security and access controls around the data.

There were three main complexities in delivering the full process. These were creating the HMAC signature, displaying the metadata and importing the image file.

Creating the HMAC signature

After the scoping sessions had confirmed the fuller requirements, I set about trying to solve the HMAC problem properly. An HMAC signature is a secure code generated from the API request and a shared secret key. Nucleus uses it to verify that each request is genuine and has not been altered before allowing access to the data. The prototype had relied on code hosted on one of my own servers. To move that into a properly managed environment, we looked at putting the signing service on AWS since Nucleus was already hosted there.

The real breakthrough came later during a call with our CTO. We went back to basics and found the actual bug. Make.com's built-in sha256() function needed its parameters in a specific order, with an empty second parameter and the secret key as the third. Once that was corrected, HMAC could be generated natively inside Make.com and we no longer needed an external server at all. It was a genuinely satisfying moment. A problem that had first sent me out to a personal server during the prototype turned out to have a native solution.

Displaying the metadata

Once I could get the data out of Nucleus, the next challenge was organising it. The prototype had relied on taking the data, using a Set Variables module to build one payload and then mapping that into the Vimeo API module.

EFA's forms can contain numerous fields for directors and other credited roles, with both the number of fields and their internal names varying between award processes. They wanted names to be comma-separated, but without commas appearing where a field was blank. That needed to work regardless of which combination of fields contained values, while ignoring the blanks and cleaning up the punctuation.

This was the most challenging problem to solve during the whole process. The Make.com interface is not well suited to writing long, nested queries and mapped values are difficult to reproduce outside the platform. It was around this time that I discovered MCP servers in Claude and was delighted to find that Claude could connect directly to Make.com and help me write the queries, which by then contained a large number of IF statements.

After a lot of trial and error, I got the queries working. The underlying problem was that they were fragile. They relied on the internal question names set by admins never changing, which was unlikely. Admins recreate forms each year and, as part of that process, field names inevitably shift.

I decided that an AI module would be the better long-term solution. AI is very good at taking inconsistent data and organising it into a defined structure. Instead of maintaining multiple long and brittle formulas, I passed the full API output into an OpenAI module with instructions to return JSON in the structure EFA required.

The output looked exactly as we needed and the main advantage was that there would be far less ongoing upkeep. As long as the AI could identify the director names, it could compile the JSON regardless of which admin-set field names sat behind them.

This was not a small technical choice. It became a central product decision across several meetings. A fully manual field-mapping build would have been cheaper to run, but it would have been tied closely to a single award configuration and prone to breaking every time a form changed.

The AI approach cost around $5 per 100 videos in OpenAI usage, but it was far more robust and could work across every award EFA ran, both now and in the future. It also meant going back to the client with an additional running cost and a change to the proposed workflow.

I had not told them upfront that the final direction would require an AI module, so I presented both options along with the advantages and disadvantages of each. They chose to continue with the AI approach. I was glad about that because I felt it delivered the best long-term value and I did not want to be revisiting the workflow every year to repair mappings that had drifted.

Importing the image file

The next big challenge was the image file. This had worked fine in the prototype, but started causing problems once we moved to an AI module and introduced additional processing time.

The source file is delivered by the API as a CloudFront link, which then serves the actual image. For some reason, this worked in the demo, but once I was building the production workflow the image import into Vimeo OTT kept failing.

After digging into it with Claude, we found that this was likely a bug on Vimeo's side. Their API appeared to be decoding part of the signed URL, which invalidated the CloudFront signature.

I do not love going back to a client with a problem that is out of my hands. Given that this was an edge case, there was no telling if or when Vimeo would fix it. I had got as far as I could on my own, so I brought it to our CTO to think through the architecture properly rather than continuing to chip away at it by myself.

The approach we landed on was to generate a unique ID, store the CloudFront URL against it in a Make.com data store and build a second scenario triggered through a webhook. That scenario would accept the ID, look up the stored URL, fetch the image and return the binary as the webhook response with the correct image/jpeg content type.

Vimeo would then be given the clean webhook URL instead of the CloudFront URL, so there would be nothing left for it to alter.

I had assumed webhook responses could not carry binary data, so this was not a route I would have reached on my own. Once we built it using Make.com's HTTP Get a File module to pull the image and a Webhook Response module to return it, it worked cleanly.

Combined with the AI mapping, this meant the same underlying webhook and prompt structure could be reused across different EFA award processes without rebuilding the integration each time the form configuration changed.

Where things stand

The workflow has been live with EFA since June 2026. There were a few rounds of real-world debugging once actual entries started flowing through it. These included a share-link expiry that was too short for longer films, a viewer permissions gap in Nucleus and an approval-status check that needed adding. These were all fairly typical of the gap between a successful test and the first real production batch.

By late June, EFA was running full batches through the workflow for a members' announcement without any issues and the feedback since has been genuinely positive.

A problem that had been sitting with EFA since 2024, and with me since I first heard about it, was quietly gone. It had been replaced by an automation that runs without anyone needing to think about it.

The workflow is still evolving. There is a director's statement field that EFA has asked to have added to the AI prompt and the error-alert emails still need a production mail domain configuring. The core problem is solved though, and it was solved with off-the-shelf tools, a lot of trial and error and a fair bit of help along the way.

Looking forward

What has changed since Part 1 is the proof point. A prototype built alone in a couple of evenings is one thing, but a system that has handled live entries for a real membership announcement without errors is something else.

The gap between the two is where most of the actual product work happened. It involved scoping the process properly, finding the real edge cases and being honest with the client about a decision they had not originally asked for but needed to weigh in on.

That is the kind of problem I am increasingly interested in. Some integrations appear to require substantial custom development, but become much more viable when they are reconsidered through automation, APIs and newer tools.