> Production API availability: use /api/v1/help?view=guides and the resource operations catalog before following a recipe. Some localhost capabilities are not deployed yet; an absent operation is unavailable.
Choose the target explicitly
Read the website and alias configuration before deploying. Confirm the board, group, website identifier and alias. Deployment targets are environment-specific.
curl --fail-with-body "$API_URL/websites" \
-H "Authorization: Bearer $API_KEY"Generate the site
This example is a mutation. Use verified identifiers for your preview target.
curl --fail-with-body -X POST \
"$API_URL/databoards/$BOARD_ID/deploy" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
--data @deploy-target.jsonThe request file contains website_id, alias, group_id and the required blog setting for the site. Preserve the deployment response and its generated path.
Run the deployment checks
curl --fail-with-body -X POST \
"$API_URL/databoards/$BOARD_ID/verify-deployment" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
--data '{"strict":true}'These checks inspect generated structure and contracts. Open the site afterward: verify desktop and mobile layouts, links, images, keyboard navigation and the relevant form or account flow.
Separate generation from activation
Generating files does not necessarily change the live route. A standalone site may need an nginx route change. The central Antsand frontend uses a release pointer so matching controllers, views and data switch together.
Do not restart services merely because content changed. Inspect the integration and determine whether any configuration reload is actually required.
Keep a way back
Retain the previous source configuration and generated release. Record the active target and the restore command before switching. A failed smoke check should restore the previous pointer; source and data restoration need their own retained snapshots.