Every web build we deliver is designed, published and handed over in Terminal.
Start a projectNeed a person? Support replies within one business day.
SupportTerminal’s CMS holds the posts, projects, products and people a site is made of. Editors work on it beside the design, pages bind to it, nothing goes live until it is published, and any front end you build reads the same content through a typed Content API.
A collection is a list of items with the same fields: a blog, a portfolio, a team, a menu, a set of locations. Start from a preset or a blank one and give it the fields the content needs, each with the rules it should keep.
Draw one card, bind its parts to a collection’s fields and make it repeat: the list takes the shape you drew, sorted, filtered, limited or paged, and an item page gives every item an address of its own.
Collections 1 collection
Showing 3 of 3 matching · 3 items in Projects. Drafts are never shown.
Text, images and their sources, links, alt text, backgrounds, attributes, colours, classes and whether an element shows at all, from the item’s own fields or a referenced item’s.
A collection’s template page publishes one page per item at its own address, and fills its search description, share title and share image from the item’s fields.
An empty field shows nothing by default. Keep the design’s placeholder or hide the element instead, add a class when a field is set, and format dates and numbers where they land.
Every item says where it stands. Edits to a live item wait for a publish, so a page can change in the CMS all afternoon while visitors, and every production key, keep reading what was live.
Add up to ten content languages and mark the fields that change between them. Each translated field holds a value per language, edited one language at a time, and anything untranslated falls back to the site’s own. The Content API serves every language you add.
The same collections, read from any front end you build: a site in your own framework, an app, a build step. Typed JSON a page at a time, with a key that lives on your server and never in a browser.
Published items only, as last published. Cached for 30 seconds. Every item as it is edited, each with its status. Never cached.
GET/terminal/api/content/v1/collections/projects?sort=opened&order=desc&limit=3
Authorization: Bearer cml_live_••••••••a41ccml_test_••••••••7e02
X-Content-Environment: productiondevelopment
Cache-Control: private, max-age=30no-store
ETag: W/"9f2c4e1a7b3d5e8f0a6c2b14"W/"3a7d0e5c9b1f4a2e8c6d0b57"
https://www.stacklumen.com/terminal/api/content/v1
/ The site, its languages and time zone, and its collections /collections/:collection A page of items: sort, order, filter, locale, expand /collections/:collection/items/:item One item, by its address or id /types A generated TypeScript module: a type per collection and a client cml_live_… Production key Published items only, as they were last published. What the live site should read. cml_test_… Development key Every item as it is being edited, drafts too, each labelled with its status. For previews. A key reads one site, or every site in the workspace, each request naming its site under /sites/:site. It only ever reads, and one made in the dashboard lasts until you revoke it unless you give it an expiry.
collection.item.published, signedEvery post on stacklumen.com/blog lives in a collection in Terminal’s CMS and is read through the Content API with a production key, the way your own code would. These are the latest, read for this page.
An agent connected to Terminal can build a collection, fill and publish it, and wire a codebase to it as a headless CMS: the key, the types and the webhook. It signs in as you, does only what you allow, and the key and webhook tools need a permission of their own.
create_collection A collection and its fields, with seed items and an item page if you like add_items Up to 500 items in one call, matched by address when you upsert publish_items Put items live, holding back any that break a field’s rules get_content_api The endpoints, the schema and the generated TypeScript for a codebase create_content_key A production or development key, shown once create_webhook A signed webhook, so a front end rebuilds when content changes Fill a collection from a spreadsheet. The preview says what every row will do, counts empty required fields and repeated unique values, and reads lists, dates and times and translations. Publish what you import in the same step, or review it first.
Import an Astro project from GitHub and its content collections become CMS collections, every item at the address it was published at, with each dynamic route as the collection’s item page, bound to the item’s fields.
No. Collections, items, publishing and binding content to a design all happen in Terminal’s designer and CMS editor. The Content API is there for teams that also want to read the same content from code of their own.
Yes. A collection is one set of items: lists and item pages built in Terminal read it when the site publishes, and a front end elsewhere reads the same items through the Content API with a key.
Not for a site published from Terminal: publishing the site publishes its new and changed items with it. A front end you host reads items through the API the moment they are published, one at a time if you like, and a webhook tells its build when something changes.
The published copy. Edits to a live item wait for a publish, so the item is marked Changed and the site, and every production key, keep the version that was live until you publish or discard the changes.
From a site’s Content → Content API page in Terminal, or Agents & API. Owners and admins make, rotate and revoke them, and every owner and admin is told when one is made. A key is shown once and stored hashed, and it can only read.
Yes. A CSV file fills a collection after a preview that counts every row, and a repository import turns an Astro project’s content collections into CMS collections with their item pages.