Convert a Make webhook file into a URL
To turn a Make webhook file into a URL, map the incoming file, buffer, attachment link, or decoded Base64 source into an HTTP module, upload the bytes to GetFileURL, then pass the returned `url` to the next scenario module.
- Reviewed by
- GetFileURL technical team
- Updated
- Input
- Make webhook file, buffer, attachment link, or decoded Base64 source
- Action
- HTTP module uploads file bytes as multipart field file
- Output
- Direct file URL plus file_id, content_type, and expires_at
- Webhook shapes
- attachment link, binary file, buffer, Base64 JSON, remote URL
- Response fields
- url, file_id, content_type, size, expires_at
- Fallback
- Decode Base64 before multipart upload
What this page answers
It turns a Make webhook file, buffer, attachment link, or decoded Base64 source into a direct URL that the next scenario module can fetch.
- Reviewed by
- GetFileURL technical team
- Last updated
Make the file handoff visible.
A useful Make webhook recipe shows the incoming file shape, the HTTP module upload, the returned JSON, and the cleanup handle.
Capture the file
Start from the Make webhook field that carries the file: attachment URL, file bytes, buffer data, Base64 JSON, or a remote URL you can fetch.
Upload and parse JSON
In the Make HTTP module, send multipart form data when you have bytes. If the webhook source gives Base64, decode it into bytes first, then upload those bytes as field `file`.
Send onward
Map `url` into the next Make module, then keep `file_id`, `content_type`, `size`, and `expires_at` beside the scenario run.
Validate the URL before the destination retries.
Most Make webhook file issues come from one of five places: wrong mapped field, expired source attachment, Base64 size limits, missing filename or content type, or a URL that expires before a retry branch fetches it.
Direct response
The URL should return file bytes, not an app preview, permission page, or redirect loop.
Useful headers
Content type, size, and disposition should match what the destination expects.
Enough retention
Expiry should account for queue delays, async processing, and retry branches.
Map the webhook input shape before picking the upload path.
Make webhook payloads do not all carry files the same way. Choose multipart when the scenario has file bytes, and decode Base64 first when the webhook source sends only an encoded field.
Attachment link
Fetch the source attachment while it is still reachable, then upload those bytes to GetFileURL.
File bytes or buffer
Use the HTTP module multipart body and send the file as field `file`.
Base64 JSON
Decode the Base64 string into bytes, keep the filename and content type, then upload the decoded file as multipart.
Remote URL
Fetch and validate the remote file first so the next module receives a stable GetFileURL URL, not a brittle source link.
Keep the returned JSON visible in the scenario.
The next Make module should receive a direct URL, while the scenario keeps enough metadata to debug retries and clean up public access.
Map `url`
Use only the returned `url` in the destination field that asks for a file URL, image URL, PDF URL, or attachment URL.
Keep metadata
Store `file_id`, `content_type`, `size`, and `expires_at` near the scenario run for logging and cleanup.
Header check
Run `curl -I <returned-url>` and confirm `200 OK` with the expected `Content-Type` before connecting OCR, AI, CRM, or support modules.
Make delayed branches need a URL that lasts long enough.
A webhook can retry or branch into async processing after the first upload succeeds. The URL should survive the real fetch window, then be deleted after success.
Retry timing
Compare `expires_at` with Make retry timing, queue delay, and any dead-letter or manual replay branch.
Cleanup
Use `file_id` or `delete_url` after the destination confirms it fetched the file.
Next proof step
If the destination fails, inspect the exact field it received before changing the upload step.
Copy the same upload shape into code
Incoming webhook file shapes:
attachment_url -> fetch bytes, then upload
file/binary -> multipart field file
base64_json -> decode bytes, then multipart field file
remote_url -> fetch, validate, then upload
Returned JSON to map:
url, file_id, content_type, size, expires_atCommon questions
What does this recipe solve?
It turns a Make webhook file, buffer, attachment link, or decoded Base64 source into a direct URL that the next scenario module can fetch.
Should the URL be permanent?
Not by default. Use the shortest retention window that survives Make retries, delayed branches, and the destination fetch.
What should I log?
Log `url`, `file_id`, `content_type`, `size`, `expires_at`, the webhook source field, and the destination response status.