Where the Client's Files Should Land

Last updated: September 18, 2026

The best outcome for a finished intake isn't a link you have to remember to open — it's a project folder that already has everything in it, and a Slack message that already told you so. BriefGate doesn't do that routing itself: there is no native Google Drive or Dropbox export, and no button that files things into a folder on its own. What it gives you instead is everything a Zapier zap, an n8n workflow, or your own script needs to do that routing for you — typed results with signed file URLs, a ZIP of the whole intake, and webhooks that fire the moment something arrives. This is the destination-side half of client intake; the collection side — what you ask for and how it gets chased — is covered in Ways to request files from clients.

Two ways to get the files out

Every file a client uploads is reachable two ways, and which one you reach for depends on whether you want individual files or the whole bundle.

Typed results, per item. `GET /v1/intakes/:id/results` (the get_intake_results MCP tool, and the action Zapier and n8n both call under the hood) returns one entry per item, keyed by its key. A file item comes back as { url, filename, mime, size, checksum_sha256 }; a file_list item comes back as an array of the same shape, one per uploaded file; an image item adds width/height. The url in every case is a signed URL valid for 24 hours — download it or hand it to the next step promptly, and if 24 hours pass before you get to it, call get_intake_results again for a fresh one. The same 24-hour window applies to the single-file endpoint, `GET /v1/intakes/:id/items/:key/files/:fileId`, which redirects straight to the signed URL instead of returning it as JSON. See item types for the exact shape each item type returns.

Everything as one ZIP. `GET /v1/intakes/:id/download` bundles every uploaded file into one archive, each in its own item's subfolder, alongside a podklady.pdf/podklady.md summary of the whole intake — labels, statuses, decisions, waivers. It's the right pick when a human is going to open the folder by hand rather than a workflow tool processing each file individually, or when you want the summary document sitting next to the files. It tops out at 2 GB (413 download_too_large); above that, fall back to typed results and fetch each file's signed URL on its own. Check `GET /v1/intakes/:id/download/preflight` first if you want the byte count before committing to the download.

Either way, this is read access to what BriefGate already has — routing it into Drive, Dropbox, a bucket, or a repo is a step your automation tool takes after the fetch, not something BriefGate does for you.

A Zapier route into a project folder in Drive

BriefGate's Zapier integration has exactly the pieces this needs: the Intake Completed trigger fires once every required item is in, and its payload already carries project_name — no extra lookup needed to name the destination folder. From there:

BriefGate: Intake Completed — trigger.
BriefGate: Get Intake Results — the search action that reads back typed values and signed URLs for every approved item.
Google Drive: Create Folder (or find-or-create, so re-running the zap for the same intake doesn't duplicate it) — named from project_name, e.g. Bella Napoli — Website.
Google Drive: Upload File — one step per file item, pointing at that item's url from step 2, dropped into the folder from step 3.

For a file_list item with several files, loop over the array (a Sub-Zap, or a Formatter step that splits it into line items) instead of one Upload File step per item — five file fields is fine as five steps, but a photo gallery of unknown size isn't. This is the same pattern the integration's own Completed intake → files in Drive example uses.

An n8n route into storage

BriefGate's n8n node covers the identical shape for a self-hosted workflow: the BriefGate Trigger node listens for intake.completed (registering a webhook on your account while the workflow is active), and its payload carries project_name the same way Zapier's does. From there, n8n's own worked example is:

BriefGate Trigger (intake.completed) → BriefGate: Get Results → an HTTP Request node per file, downloading each signed URL → a storage node (Google Drive, or n8n's built-in Dropbox node for a Dropbox destination) uploading it into a folder named after the client or project.

The HTTP Request step matters: a signed URL is a direct download link, not something the Drive or Dropbox node can point at as a remote source — fetch the bytes yourself and pass the binary data downstream. Three ready-to-import templates built on this and two other patterns are linked from n8n's resources.

A Slack notification that says what's arrived

BriefGate can post to Slack directly, without a workflow tool in between: register a webhook with "format": "slack" and BriefGate posts a plain sentence to the channel for each event you subscribe to — see Webhooks: Slack and Discord. Subscribed to item.submitted, that's one line per file as it lands (The client submitted "logo" for Bella Napoli — Website.); subscribed to intake.completed, one line when the whole thing is done. That's the fast path for "let the team know," and it needs no automation platform at all.

Saying what's still missing takes a step further than the built-in format goes — compose it yourself in Zapier or n8n: trigger on item.submitted or on a schedule, call get_intake_status (or read the missing array get_intake_results returns) for the intake's current progress, and post "3 of 5 items in for Bella Napoli — Website. Still waiting on: hero copy, opening hours." BriefGate's webhook supplies the raw event; your workflow tool supplies the summary — the same combination behind the Zapier and n8n "heads-up in Slack" examples.

Naming and foldering that survives more than three projects

A folder-per-client scheme that works for the first three projects usually breaks by the tenth, once two clients share a name or a project gets renamed halfway through. A few things keep it working:

Name the destination folder from project_name, not the client's name alone. It's on every relevant webhook payload and on the results response, so no extra lookup is needed, and it disambiguates a client with more than one project running at once.
Include the intake id somewhere stable — the folder's description, a hidden marker file, or a spreadsheet row keyed by intake_id — so renaming project_name later doesn't orphan the automation's find-or-create step, which would otherwise create a second folder instead of reusing the first.
Match BriefGate's own folders (folder_id) to your Drive/Dropbox structure if you use both. BriefGate's folders only organize the dashboard's intake list and don't drive anything on the Drive/Dropbox side, but keeping the two in sync gives "where did this intake's files go" one consistent answer instead of two.
Borrow the ZIP's own filename convention — podklady-<project>-<intake id>.zip — as a naming reference that already bakes in both fields (see ZIP download).

Secrets are deliberately excluded from automation

None of the routes above should ever carry a secret item — and by default, they can't. Zapier's Get Intake Results search action always sends exclude_secrets=true: secret items are left out of the response entirely, without being revealed, because Zapier keeps every step's output in your Zap history and a secret can only be revealed once, ever, across the whole account (see Secrets vault). The same reasoning holds for any n8n workflow or script you write yourself — call get_intake_results with exclude_secrets: true, or simply don't grant the API key the secrets:read scope, and a wp_admin password can't end up piped into a Drive file, a Dropbox folder, or a Slack channel by accident.

Read a credential in the dashboard instead, where the owner's Reveal click is the one-time reveal itself and the value never touches a webhook payload, a Zap history, or an n8n execution log. If it needs to reach a teammate, that's a deliberate second step through your own secrets manager — not something that should ever be automatic.