Content API reference

Every tenant is one document in the sites collection. Its key field (the siteKey) identifies the tenant; consumer apps authenticate with the site's API key, which resolves to this document.

All other content documents carry a siteId field referencing the owning sites document. companies and siteSettings are one-per-site; legalTexts is one-per-document-key; services, products, projects, posts, testimonials, faqs, locations and values are one-per-slug within a site; assets are one-per-pathname.

All documents also carry MongoDB _id, createdAt and updatedAt fields managed by the database layer; they are omitted from the tables below.

The platform owns design-agnostic business data only: business identity and contacts, opening hours, the services performed, the products sold, the projects published, the posts written, the testimonials received, the questions answered, locations, company values, and the legal documents the client maintains. Every client website has its own bespoke design, so page structure, layout, section copy and metadata (band headings, stat figures, call-to-action labels, intro blocks) live in the client site's own repository and are deliberately absent from this contract.

Each resource maps to one collection: settings to companies, services/products/projects/testimonials/faqs/locations/values to their per-slug collections (array position stored in each document's order field), posts to the posts collection (ordered by the publishedAt date each post carries rather than by a sort index), and legal to one legalTexts document per document key. Platform-only data never leaves: companies.availability is the schedule designer's working data (client sites read the schedule lines derived from it), posts.status decides whether a post is served at all rather than being served alongside it, and the whole siteSettings document holds backoffice preferences.

A service is work scoped per job and carries no price; a product is something sold at a stated price, stored as an amount plus its currency and billing period so each website can format it in its own style; a project is work already delivered, told as problem, solution and results; a post is something the business wrote, dated and published on its own decision; a testimonial is what somebody else said about the business, optionally rated and attributed; an FAQ is one question and its answer, grouped under a heading the tenant chose.

Resource responses omit siteId and every platform-only field, and they are fully defaulted: missing strings come back as empty strings and missing arrays as empty arrays. A site with no content yet returns valid empty resources rather than an error, so client sites can render an empty state.

One field is markup rather than text: a post's body is an HTML fragment. It is sanitised against a fixed element allowlist when the tenant saves it, so what the collection stores is already what may be rendered, and a consumer inserts it as HTML rather than escaping it. Every other text field on this contract is plain.

Two collections are served with a document withheld rather than flagged, so a consumer never has a state to check: an unpublished post, and a testimonial created but not yet written. Everything else in a collection is served as stored.

Every uploaded file lives in the assets collection, stored in Vercel Blob through the backoffice. The pathname is the storage key and stays internal: the Site API delivers each file as an absolute url on the store's CDN, which a client site uses directly. A service, a product, a testimonial or a post's cover embeds the pathname of its single image; a project references whole asset documents, so its files arrive with their kind, MIME type, name, size and pixel dimensions resolved. A post does both: the images inside its body carry their URLs in the markup, and the document lists the asset ids behind them so an image still in use is never retired.