Client Portal

Try it yourself. Open a demo portal — no account, no sign-up. It is a real intake on the real portal, so what you see is exactly what your client sees. It deletes itself within a day.

Overview

When you call define_intake, BriefGate generates a unique branded portal URL (e.g. https://p.briefgate.dev/8f3k) and emails it to your client with a magic link. The client does not need to create an account. They click the link, land directly in their portal, and start submitting assets.

On paid plans, the portal shows your branding — not BriefGate's. From the client's perspective, this is a tool you built for them.

Once the client starts submitting, review what came in from the intake detail page in the dashboard, or pull everything at once as a ZIP — see Download Everything as a ZIP.

Magic link flow

Client receives an email with a magic link containing a token
Client clicks the link; the browser sends POST /portal/:slug/redeem to exchange the token for a session cookie
The cookie grants access to that specific intake only (not other intakes), and is valid for 14 days
If the client loses the email, trigger a re-send: POST /v1/intakes/:id/send (or use send_chase from MCP)

The magic link is not single-use, and it's also not one-per-email: an intake has one stable link for its whole life, and every email about it — the invitation, each reminder, a manual chase — carries that same link. It stays valid for the account's portal link validity setting (portal_link_ttl_days, default 30 days, configurable 1–365 in the dashboard), counted from the most recent email sent for that intake, so every send extends the window instead of replacing the link. The token itself is derived server-side from the intake and a server secret, and only its hash is stored — never the token, never in plaintext.

The practical consequence: whoever holds the link holds access to that intake for as long as the intake keeps getting emails (or until portal_link_ttl_days passes since the last one). Treat a forwarded invitation email the way you would treat a forwarded document. Deleting or anonymising an intake stops its link from working, regardless of the TTL.

What the client sees

Your branding: logo, accent color, sender name (on paid plans); the same logo and an optional e-mail signature image (a business card works well) appear in every e-mail the client gets from you
Project name and a headline naming your business ("Radim needs your assets") — the client's own name is not shown in a greeting
A progress bar ("5 of 8 complete")
All items listed with their labels, help text, and current status
A "Send assets" button that marks the intake complete and fires the intake.completed webhook

On the Free plan, "Powered by BriefGate" is shown at the bottom of the portal. This is removed on Solo, Studio, and Agency plans. Custom portal domain (e.g. intake.yourcompany.com) is available on Studio and Agency — see Custom Domains for setup.

Client brief

Sometimes the information needs to flow the other way first — a contract offer to sign, a scope document, a few paragraphs of context before the client fills anything in. Set client_brief on define_intake (or PATCH /v1/intakes/:id afterwards) and attach files with POST /v1/intakes/:id/brief/files; both are documented under POST /v1/intakes and Client brief in the REST API reference.

When either is set, it appears above the requested items as "Information from <your name>" — the same sender name the invitation e-mail signs with. Attachments go through the identical pipeline a client's own upload does: real content-type sniffing, HEIC-to-JPEG conversion, and an antivirus scan before the file is ever shown as downloadable. A file still being scanned, or one the scanner flagged, shows in the portal without a working link until it clears — the client is never handed a file BriefGate has not vetted.

The invitation and reminder e-mails add one line pointing the client at the portal when a brief is present, but never attach the files themselves — email attachments bypass the antivirus/quota accounting this whole product is built around, so the client always has to open the portal to see them.

Thank-you e-mail

The moment an intake completes — whether the client clicked "Send assets" or you marked the last item as received outside BriefGate — the client gets one short thank-you e-mail in the intake's language, confirming that everything arrived and you can continue. It is on by default, sent once per intake and never for intakes created with a test-mode key. Switch it off with Send a thank-you e-mail to the client when everything has arrived in Settings (or send_client_thank_you: false on PATCH /v1/account) if you prefer to close the loop yourself; the intake.completed webhook and your own notification are unaffected.

Item interactions

Each item type renders a specific UI:

text / longtext — standard input or textarea with live character count
file / image — drag-and-drop upload area or camera/gallery picker on mobile, progress bar during upload
file_list — an "Add files" picker (camera/gallery on mobile), progress bar during upload; unlike file/image there is no drag-and-drop area
color_list — a color swatch plus a hex text input per entry (there is no separate singular color item type — only color_list)
select — dropdown
boolean — a Yes/No button pair
url — URL input with format validation on blur
secret — masked input with lock icon; the value is sent over HTTPS and encrypted server-side (public-key sealed box) before being stored — it is not encrypted in the browser, and it is never sent back once saved
structured — a simple form auto-generated from JSON Schema; key/value pairs for objects, repeated rows for arrays

All items autosave on every field change. If the client closes the browser mid-way through, their progress is saved and they can return via the same portal link without re-entering anything.

Mobile-first

The portal is designed for clients submitting from a phone. Key mobile behaviors:

File inputs trigger the camera or photo gallery on iOS and Android
HEIC images from iPhone cameras are converted to JPEG server-side automatically — clients do not need to convert files themselves
Progress is preserved across page reloads and browser restarts
Uploads show a live progress bar; there is no chunked or resumable upload, so a dropped connection mid-upload needs a retry (files already saved are kept)

In-portal validation

Clients see validation errors in two layers, before and after anything is sent:

In the browser, before any request is sent — basic checks run instantly as the client picks a file or leaves a field, e.g. "Please enter a valid URL (https://...)" or "Image too small — we need at least 512px wide".
On the server, on submit/upload — BriefGate independently re-validates every value and file it receives and returns a detailed message if something still doesn't pass, e.g. "This image is only 200px wide; we need at least 512px." or "This file is 28 MB; the limit is 20 MB."

The browser-side check is a courtesy that catches the obvious cases before the client hits Send assets, reducing revision cycles; the server-side check is authoritative and cannot be bypassed by a client that skips the browser check.

Languages

The portal UI is available in:

Code	Language
`en`	English
`cs`	Czech
`sk`	Slovak
`pl`	Polish
`de`	German
`es`	Spanish

Omit client.language and the account's default_language applies; with neither set, the portal falls back to English.

Set at define_intake time via client.language. All labels, help text, buttons, and system messages are shown in the chosen language. The item label and help fields you define are shown as-is — translate them yourself when using a non-English language.

Additional languages are planned. Contact support to request one.

Revision flow

When the agent calls request_revision(intake_id, item_key, note), the portal flags that item with a banner showing your note:

"This logo is too small. Please upload at least 512px wide. The SVG version would be ideal if you have it."

The item's status changes to needs_revision. The client receives an email notification, clicks back to the portal, and re-uploads or re-enters the item. When they submit, item.submitted fires again and the item status returns to submitted.

On Free plan, revision requests are not available (plan_required error). Available on Solo, Studio, and Agency.

"Powered by BriefGate"

On the Free plan, a small "Powered by BriefGate" notice appears at the bottom of the portal, and again on the "Done!" screen once the client submits everything. Both link to https://briefgate.dev. Right next to each one is a second, smaller line — "Collecting files from your own clients? Try BriefGate →" — pointed at other people running an intake of their own, not at your client. Client-facing emails (invite, reminder, revision request, completion notice) carry the same line in their footer.

Both notices are removed entirely on Solo, Studio, and Agency plans — there is no separate toggle for the referral line; it disappears together with the branding it sits next to. On Studio and Agency, you can also configure a custom portal domain so the URL itself shows your brand (e.g. intake.yourcompany.com instead of p.briefgate.dev/8f3k) — see Custom Domains.