Collections and site data
Two different shapes of content
A website for a trade needs content with structure — a roofer's services, a restaurant's menu, a studio's portfolio. A template can ship that structure so a buyer starts with the right shape and only has to fill in their own words.
It comes in two halves, and the difference is simply whether there are many of something or one:
{
collections: [ /* … */ ], // many of something
siteData: { /* … */ }, // one object, for everything else
}
collections is a list of repeating content types. Services, Testimonials,
Projects, Menu items — anything a buyer will have several of, each with the same
fields. Each becomes a real collection on their site that they can add rows to.
siteData is a single object for everything that exists once: the headline on the
homepage, the opening hours, the strapline under the logo. It can nest as deeply as you
like, and it is read all the way down.
Forms are optional
A template may ship its own forms, and does not have to. Every BusinessDash organization already has a general enquiry form, and a contact block with no form of its own connects to that.
Ship forms when the trade needs something specific — a quote request with roof pitch and square footage, a booking form with party size and seating preference. Do not ship a form that is just "name, email, message", because one already exists.
Where your template may call from
If your template's pages call the BusinessDash API from the browser, declare the origins they call from:
| Entry | Meaning |
|---|---|
self | The buyer's own site. Resolved on install — no review needed. |
custom-domain | Whatever domain the buyer has connected. Also resolved on install. |
| A literal origin | A specific third-party origin, e.g. https://studio.example |
Use self and custom-domain wherever you can. They mean "wherever this buyer's site
lives", so they work for everybody and need no explanation.
A literal origin is a request for the buyer's API to accept calls carrying the buyer's
key from somewhere else. A reviewer will look hard at one, and the buyer is shown it at
install. Wildcards are refused outright — there is no version of * that is safe to grant
on someone else's behalf.
Names you cannot use
Some names belong to the platform and a template may not claim them — staff, chat,
tasks, schedule, conversations, users and their obvious variants, in a collection
name or a top-level siteData key.
These exist because the demo everyone browses is populated by BusinessDash, identically for every template: a staff roster, internal chat, a schedule, customer conversations. It is supplied once so that every template demos against a business that looks real, and so that no creator has to invent a cast of people.
Names that merely contain a reserved word are fine. staff-picks is yours; staff is
not.
Limits
Untrusted content gets bounds, so a template cannot land a buyer's site with something unusable:
- nesting up to 12 levels deep
- a few thousand entries per object
url(...)anywhere in it must name a file you shipped
If you are hitting these, the content probably belongs in a collection rather than in
siteData.