One list, every project
The first restaurant website you build, you type out the item list from scratch: logo, hero copy, the restaurant's story, opening hours, a gallery of food and interior shots, maybe a menu PDF. The second restaurant website, you're typing almost the same list again — same items, same constraints, different client. A template exists so that the second time is a click, not a re-type.
A BriefGate template is a saved set of item definitions — key, type, label, constraints, all of it — that you point a new intake at instead of building items one by one. define_intake (or the dashboard's New intake screen) fills the intake with everything the template holds, and you're free to still adjust it for the specific client.
Build the list once
The moment you notice you're asking for the same things on a third project in a row, that's the list worth saving as a template. It doesn't have to be perfect the first time — the point of a template is that it's easy to revise once and reuse many times, unlike a one-off item list you'd have to remember to update everywhere it was copied.
Two ways to get a template into your account:
- From the dashboard, build an intake the normal way and click Save as template next to the Send button once you're happy with the item list. It stores the item definitions and the language — deliberately never the client's name, e-mail, or project name — so the exact same template is safe to hand to the next client without editing out anything personal.
- Through the API,
POST /v1/templatesbuilds a template from scratch (there is no endpoint to copy an existing intake into one — that direction only works from the dashboard button). You give it aname, alanguage(cs,en, orde), and anitemsarray in the same shapedefine_intakeexpects. There's noslugfield to set; the slug is derived fromnameautomatically.
Custom templates — the ones you build yourself — need a Solo plan or above. On Free, POST /v1/templates returns a plan_required error, and the dashboard button isn't available either. That's not a limitation you fight around for long, though: Free still gets the three built-in templates below, which cover a real project type each.
Three you don't have to build
Every plan, including Free, has three public templates available from day one:
restaurant-web-cs— logo, hero copy, the restaurant's story, opening hours, a photo gallery, an optional menu PDF, optional brand colors, and an optional GA4 tracking ID.advisor-web-cs— logo, a professional portrait, a one-line headline, a longer bio, up to six services, optional brand colors, and contact details.club-web-cs— logo, a motto, the club's history, founding year, what the club does and when it meets, an optional event gallery, contact details, and optional social links.
All three are Czech-language templates — their labels and help text are written in Czech, since they were built for real agency work rather than as generic placeholders. (There's currently no built-in e-commerce template; club-web-cs is for clubs and associations, not stores.) They can't be deleted and are always there, which makes them a safe default to start from even if you end up changing half the items.
Point define_intake at one with the template field:
{
"project_name": "Bella Cucina Restaurant Website",
"client": { "email": "owner@bellacucina.cz", "name": "Marco" },
"template": "restaurant-web-cs"
}items becomes optional once template is set — omit it, or send "items": [], and every item comes from the template. Without a template, items is still required and non-empty, same as always.
See Item types for what each type validates, and the full item tables for all three templates in Templates.
Adjust without starting over
A template rarely fits a project perfectly, and it doesn't need to. Send an items array alongside template and BriefGate merges it with the template's own items: a key that matches a template item overrides that item, and a new key gets appended after the template items.
{
"template": "restaurant-web-cs",
"items": [
{
"key": "menu_pdf",
"type": "file",
"label": "Menu (PDF)",
"required": false,
"help": "Only needed if you want a downloadable menu link."
},
{
"key": "allergen_info",
"type": "file",
"label": "Allergen information document",
"required": false
}
]
}One catch worth knowing before you try to save a keystroke: every entry in items has to be a complete item definition — key, type, and label are all required — even when all you actually want to change is whether it's required. There's no shorthand for patching a single field of a template item.
Carry more than items
A template can also hold every other setting a new intake needs besides its items: chase cadence, retention rules, branding, which folder new intakes land in, even a client brief. POST /v1/templates accepts an optional settings object with due_in_days, chase_schedule, respect_quiet_hours, max_reminders, email_copy, retention, branding, folder_id, and more — see Templates for the full field list.
These are defaults, not overrides: when you create an intake from a template, a field from settings applies only where the create-intake request leaves that field unset. Anything the request states explicitly always wins. due_in_days gets resolved into a real due_date at the moment the intake is created — a template can't carry a fixed calendar date, only an offset from whenever it's used.
This is API-only for now. The dashboard's Save as template button still stores items and language only; if you want a template that also sets the chase cadence or branding, build it through POST /v1/templates.
Where the payoff shows
The first project with a new template costs you the same time it always did — you're still deciding what to ask for and writing the help text that makes each item make sense to a client who's never filled in an intake before. The second project is where it pays off: you point define_intake at the template, add the two or three things that are different about this particular client, and send. What used to be twenty minutes of writing item definitions is now the couple of minutes it takes to fill in a client's name and adjust one due date.
On an Agency plan, that payoff extends across the team automatically — a template any seat creates is visible to every seat on the account, with no separate sharing step. If you're building a library across several project types, naming slugs consistently (restaurant-web-v2, advisor-web-minimal, webapp-onboarding) keeps them easy to tell apart as the list grows.
Related
- Templates — full reference, including all built-in item tables and the
settingsobject - Item types — what each item type validates and returns
- Dashboard quickstart — creating an intake from the browser, templates included