One list, every project

Last updated: · By Radim Sekera

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:

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:

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:

json
{
  "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.

json
{
  "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.