What is your goal?
Like Make to send my Vapi audio messages/recordings to an email summary report that will allow the user to click the link or button and listen to the interaction between AI and caller.
What is the problem & what have you tried?
VAPI is recording the audio and saving but not picking up the file to my MAKE scenario and pushing to email.
Error messages or input/output bundles
This XML file does not appear to have any style information associated with it. The document tree is shown below.
InvalidArgument
Authorization
Is the XML error appearing in Make’s recording-download step, or when you click the recording link? The error alone does not establish the cause.
If the recording is in Vapi’s private storage, Vapi’s retrieval guide says the storage URL is not directly downloadable. The documented route is GET https://api.vapi.ai/call/<CALL_ID>/mono-recording with Authorization: Bearer <PRIVATE_API_KEY>. Replace <CALL_ID> with the actual call ID and keep the key in Make’s authenticated request, never in the email.
That endpoint returns a 302 redirect to a short-lived signed download URL. Check that your HTTP step follows the redirect and retrieves audio. For the Listen link in your summary email, you could save that audio to storage that grants the intended recipient access, then include its sharing link. The temporary Vapi download URL will expire, so it is unsuitable for a lasting email link.
Which Make module retrieves the recording, and what HTTP status does it return? A redacted screenshot of that step’s configuration and error would help; remove API keys, signed URLs and caller details.
That XML is the storage bucket answering, not Vapi, and the two words in it are the whole clue. InvalidArgument with Authorization as the argument name is S3’s “only one auth mechanism allowed” error.
What that means: the Vapi recording URL is already a pre-signed URL, so the credentials are baked into the query string. If your HTTP module also sends an Authorization header, or has a connection attached, S3 sees two auth methods and rejects the request outright. It isn’t a permissions problem, which is why adding credentials makes it worse rather than better.
Try HTTP > Get a file, paste the recording URL exactly as Vapi returns it, with no connection and no headers. The URL carries its own auth.
Two things that bite after that:
Those signed URLs expire. If you email the raw link and someone opens it the next day it can fail, even though it worked in your test run.
And for “click and listen” you may not need the HTTP module at all. You can drop the recording URL straight into the email as a link. That inherits the same expiry problem though, so if people need to listen weeks later, fetch the file once, put it in Drive or your own bucket, and link that instead.
One question: is the URL going into the HTTP module the one from the end-of-call report webhook, or one you’re assembling from the call ID? Those don’t behave the same way.