Workflow recipe

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
webhook file to URLMake HTTP modulemultipart uploadcontent_typeexpires_at
Recipe shape
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
Short answer

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
Steps

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.

01

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.

02

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`.

03

Send onward

Map `url` into the next Make module, then keep `file_id`, `content_type`, `size`, and `expires_at` beside the scenario run.

Checks

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.

01

Direct response

The URL should return file bytes, not an app preview, permission page, or redirect loop.

02

Useful headers

Content type, size, and disposition should match what the destination expects.

03

Enough retention

Expiry should account for queue delays, async processing, and retry branches.

Make webhook map

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.

01

Attachment link

Fetch the source attachment while it is still reachable, then upload those bytes to GetFileURL.

02

File bytes or buffer

Use the HTTP module multipart body and send the file as field `file`.

03

Base64 JSON

Decode the Base64 string into bytes, keep the filename and content type, then upload the decoded file as multipart.

04

Remote URL

Fetch and validate the remote file first so the next module receives a stable GetFileURL URL, not a brittle source link.

Response proof

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.

01

Map `url`

Use only the returned `url` in the destination field that asks for a file URL, image URL, PDF URL, or attachment URL.

02

Keep metadata

Store `file_id`, `content_type`, `size`, and `expires_at` near the scenario run for logging and cleanup.

03

Header check

Run `curl -I <returned-url>` and confirm `200 OK` with the expected `Content-Type` before connecting OCR, AI, CRM, or support modules.

Retry safety

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.

01

Retry timing

Compare `expires_at` with Make retry timing, queue delay, and any dead-letter or manual replay branch.

02

Cleanup

Use `file_id` or `delete_url` after the destination confirms it fetched the file.

03

Next proof step

If the destination fails, inspect the exact field it received before changing the upload step.

Examples

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_at
FAQ

Common 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.