Campaigns

A campaign is the fast way to go from an idea to a stack of finished creatives. You describe what you need; braaand picks suitable templates, writes copy that fits the message, renders every variant, and scores them. You review the results on a board, keep the ones you like, and ship.

Every campaign is a workflow — a durable node pipeline that keeps working even if you close the tab. This page is the quick path; when you want to see or change how the creatives get made, open the run on its canvas (workflow builder) — every run is a pipeline you can inspect, tweak and re-run.

Starting a campaign

Three ways in, all the same engine underneath:

• Just ask. In the command palette, say what you want: "give me three creatives about saving the forest" or "here's our spring campaign, I need ten creatives." braaand picks a recipe and launches a run, then hands you a live progress card with two ways to watch it — a calm build screen, or the node editor showing the pipeline work in real time. Runs keep going after you navigate away, and you get a notification when they're done. A small ask uses the plain Batch recipe (no scoring — you're the judge); a bigger one uses Reviewed campaign; "five variations of this one" uses Variations of this, seeded from the creative you're pointing at.
• The Factory. Factory → Workflows → New opens a chooser with four doors: a quick brief form (describe the campaign in a few sentences and launch), the node canvas seeded with the default pipeline, a blank canvas to build a graph from nothing, or from a recipe — a built-in starter or a graph you saved, loaded as a draft with the brief ready to fill in.
• From your own tools. An external system (or a coding agent like Claude Code) can hand braaand a brief over the API or MCP and get back a link — see For builders below.

You don't have to pick templates by hand — braaand matches the brief to the templates that fit, including how much copy each layout holds, so a punchy one-liner and a detailed list each land on the right kind of template. But you can: pin exact templates on the Templates node and matching is skipped — the run builds on your picks, in the order you pinned them.

A campaign launched from a plain brief gets the default pipeline: find templates, build the creatives on them, score, then route the batch by score — 75 and up lands in an "Approved" section on the board, the rest in "Needs review" — so the results arrive pre-sorted instead of loose. Want different routing, per-template treatments, extra editing passes, or your own board sections? That's all wiring — see the node reference.

Reviewing the results

The run's creatives land on a board: pre-sorted sections, keep/discard on every card, a chat that iterates on the batch (or on exactly the cards you select), and a public share link for sign-off that needs no braaand account. See Boards.

Where it all lands

Every run files itself into a collection, named from the run unless you name one at launch. The collection gathers the whole campaign in one place — the run, its board, every creative, and what it cost. Rename an auto-named collection to make it a proper campaign, and launch follow-up runs into the same collection to keep building on it.

Variety from few templates

The same template in a different color scheme reads as a fresh creative. So even a brand with only a couple of templates gets a varied batch: braaand recolors across your color schemes (and writes a fresh angle each time) to give you range, not repeats.

For builders

Campaigns are also an integration surface. An orchestrator (your own service, a campaign tool, a coding agent) can delegate the entire creative job to braaand and preview the results in its own product:

1. Hand over a brief — POST /api/brands/{brandId}/factory/workflows (or the start_workflow MCP tool) with { "brief": { "raw": "..." }, "count": 10 } — the brief is free text, so how many creatives you want goes in count, not the prose. Add templateIds to pin exact brand templates instead of automatic matching. For control over the pipeline itself (how many creatives, whether to score, how to route), pass a node graph instead, or use the build_pipeline MCP tool. Pass collection (a campaign name, created if needed) or collectionId to say where the work files; otherwise it auto-files by run title. You get back { workflowId, boardId, collectionId, boardUrl, shareUrl, manifestUrl }. braaand owns the rest.
2. Poll the manifest — GET .../factory/workflows/{workflowId}/manifest (or get_workflow) returns the run's live status; get_board returns the board's full content — every creative that's landed on it (from this run or any other), current render URLs (per format), score, and keep/discard state.
3. Stay in sync — render URLs are content-hashed, and manifests are computed fresh on every read, so any edit (on the board or ordered through your tool) shows up on the next poll. No webhooks needed.
4. Hand a human a link — shareUrl is a public, read-only review page that needs no braaand account, so you can pass it straight to whoever signs off. (boardUrl is the same review surface for someone signed in to the brand, where they can also keep/discard and iterate.) A coding agent can simply produce the batch and pass the link along.

The authed manifest's render URLs are brand-access gated — fetch them server-side with the same token you used to start the run. The shareUrl and its public manifest (/api/share/board/{token}) carry a delivery token that authorizes just that board's renders, so a recipient with the link can view them without an account. Mint or revoke the link any time with POST / DELETE .../boards/{boardId}/share.

For a full accounting of one run — what it built, what it scored, what it cost — pull its shareable log: GET .../factory/workflows/{workflowId}/log (or the get_workflow_log MCP tool). Every id in it resolves back to what it is via GET /api/resolve/{id} (or resolve_id).

Cost

Campaign production draws credits from the plan that pays for the brand — the Team pool for a brand that belongs to a team, the brand owner's plan otherwise — the same pool the in-app agent uses. A brand whose pool is empty (or whose plan doesn't include AI) gets a clear "payment required" response instead of a run.