# Overview

Five editorial content types - blogs, docs, FAQs, testimonials, and rich content - authored in the console.

The content module holds editorial entities you want non-engineers to edit:
marketing pages, help articles, FAQ groups, testimonials. They are authored in
the console and read over the API.

```bash
curl -G https://api.console.buildbase.app/api/blogs \
  -H "Authorization: $BUILDBASE_TOKEN" \
  --data-urlencode 'filter={"published":true}' \
  --data-urlencode 'sort={"createdAt":-1}'
```

> **Note:**
  Author content in the BuildBase console. Every endpoint here is
  token-authenticated, so a public website reads it from your own backend or at
  build time — not directly from the browser.


## The five types

| Type             | Base path           | Shape                                             |
| ---------------- | ------------------- | ------------------------------------------------- |
| **Blogs**        | `/api/blogs`        | Posts in folders, with tags and authors           |
| **Docs**         | `/api/docs`         | Same structure as blogs, separate tree            |
| **FAQs**         | `/api/faqs`         | Groups, each holding an ordered list of questions |
| **Testimonials** | `/api/testimonials` | Quote, attribution                                |
| **Rich content** | `/api/rich-content` | A named block of rich text, fetched by slug       |

Blogs and docs share an implementation — folders, paths, tags, authors, drafts —
so [one page covers both](/content/blogs-and-docs).

## Rich content

Rich content is the simplest and the most useful of the five: a named block of
formatted text your app renders wherever it likes. Terms of service, an
announcement banner, a pricing footnote.

Fetch it by slug rather than id, so the reference in your code stays readable:

```bash
curl https://api.console.buildbase.app/api/rich-content/slug/refund-policy \
  -H "Authorization: $BUILDBASE_TOKEN"
```

## FAQs

FAQ **groups** are the top-level record; individual questions are managed inside
a group rather than as standalone documents:

| Method  | Path                             | Purpose                           |
| ------- | -------------------------------- | --------------------------------- |
| `GET`   | `/api/faqs`                      | List groups                       |
| `GET`   | `/api/faqs/:id/faqs`             | Questions in a group              |
| `PATCH` | `/api/faqs/:id/faqs/add`         | Add a question                    |
| `PATCH` | `/api/faqs/:id/faqs/update`      | Edit a question                   |
| `PATCH` | `/api/faqs/:id/faqs/remove`      | Remove a question                 |
| `GET`   | `/api/faqs/:id/faqs/suggestions` | Suggested questions for the group |

Reordering and editing therefore happen through the group, which keeps question
order stable without a sort field on every item.

## Content is not assets

This module stores **text**. Files — images, PDFs, downloads — belong to
[assets](/assets/overview), which handles upload, storage, and public or private
URLs.

The two connect by reference: rich text embeds an asset's URL. Uploading an
image while editing a post creates an asset record; the post stores the link to
it. Deleting a post does not delete the asset.

## Next Steps

- [Blogs and docs](/content/blogs-and-docs) — folders, paths, and drafts.
- [Assets](/assets/overview) — the files this content links to.