Style an ANTSAND website in 7 steps

Complete API-driven workflow for AI styling ANTSAND Databoard websites.

The loop is inspect, patch, compile utilities, deploy, smoke test, and iterate.

AI Quick Start

API Reference Databoard Concept

One API key

Authenticate once and operate on behalf of the Databoard owner.

Data-first

Write content to databoard.menu topo, then map sections to that source.

Compile loop

Utilities, Sass, Volt, routes, ACL, and deployment stay in one pipeline.

Smoke-testable

Every generated page can be verified with HTTP and semantic contract tests.

The API loop agents should follow

Each step is intentionally small and repeatable. Do not skip directly to styling until the data source and mapping are valid.

Workflow

List boards

Find the board id and confirm the API key belongs to the correct user.

List boards bash

curl -H "Authorization: Bearer YOUR_API_KEY" /api/v1/databoards

1 GET

Inspect the board

Read list, menu, sass, page settings, and existing section mappings.

Inspect board bash

curl -H "Authorization: Bearer YOUR_API_KEY" /api/v1/databoards/{BOARD_ID}

2 GET

Write source data and mappings

Use patch_delta ensure_menu for editable data and ensure_section for template mapping.

Mapping contract json

{"data_mapping":{"api_data":[["api_data"],["databoard","menu","stylesdoc_hero"]]}}

3 PATCH

Compile utilities

Scan css_class fields and emit board-local utility CSS for the classes used by this site.

Compile utilities bash

curl -X POST -H "Authorization: Bearer YOUR_API_KEY" /api/v1/databoards/{BOARD_ID}/utilities/compile

4 POST

Deploy

Generate controllers, views, routes, ACL, assets, api_data.json, and the deployable Phalcon app.

Deploy bash

curl -X POST -H "Authorization: Bearer YOUR_API_KEY" /api/v1/databoards/{BOARD_ID}/deploy

5 POST

Smoke test

Confirm the public route returns clean HTML/HTTP before iterating further.

Smoke test bash

curl -s -o /dev/null -w "%{http_code}" http://YOUR_SITE_URL/docs/agentquickstart

6 GET

Iterate in small patches

Patch one section at a time. If a pattern repeats, promote it to a renderer/Sass contract and add a test.

7 Repeat

Content is owned by menu/module data. Templates own preview/fallback shape. Data mapping connects them.

What to change where

Most styling changes belong in Databoard field CSS. Reusable visual language belongs in Sass v2 only after it repeats.

Reference

Field CSS

Use for section-level and field-level classes: section.container, data.container, data.sub_container, data.h3, data.p, data.cta.

Board Sass

Use for website-specific classes and brand-specific layout. It compiles into common_styles for that board.

Utility compiler

Use after field classes are assigned. It scans css_class values and emits needed utilities into board Sass.

Sass v2

Use only for reusable framework behavior: nav, cards, buttons, docs code blocks, accessibility, themes.

service_3_modern

Use when content fits Header / Body / Footer. Most docs, cards, hero, CTA, nav, footer, and prose sections fit.

New renderer

Add only when the same non-H/B/F pattern repeats, such as live component examples or rich API tables.

Databoard Concept API Reference

Common mistakes the API should prevent

These are the failures that made the migration noisy. They should be visible to agents before deployment.

Troubleshooting

Do not write real content into template api_data

section.data.api_data is preview/fallback. Real editable data belongs in databoard.menu..topo or the owning module.

Do not merge numeric mapping arrays recursively

data_mapping.api_data[0] and [1] are an atomic destination/source pair. Replacing them avoids corrupt paths.

Route identity beats display title

Multiple pages can be named Databoard, Index, or Buttons. The page route is the true identity.

Topnav/footer should be shared sources

Every page maps to stylesdoc_topnav and stylesdoc_footer so global navigation updates once.