For AI agents
Put a working widget on a site you are building. Everything in one fetch:
/llms-full.txt.
| Step | Endpoint | Credential |
|---|---|---|
| 1. Read the contract | GET /api/public/config-schema | none |
| 2. Assemble the config | — | none |
| 3. Validate, repeat until valid | POST /api/public/configs/validate | none |
| 4. Find the business, create a draft | GET /api/businesses/current, POST /api/businesses/{id}/configs | X-Owner-Token |
| 5. Publish | POST /api/configs/{id}/publish | X-Owner-Token |
| 6. Embed | — | publishableKey |
Public endpoints are on https://mindthefront.com, owner endpoints on https://console.mindthefront.com.
1–3. Build and validate without an account
curl https://mindthefront.com/api/public/config-schema -o schema.json
curl -X POST https://mindthefront.com/api/public/configs/validate \
-H "Content-Type: application/json" --data @config.json
{ "valid": false, "errors": [
{ "path": "/flow/steps/confirm", "rule": "flow-lint",
"message": "Field \"phone\" is required but is not filled on every path to the submit step \"confirm\"" }
] }
rule | What is wrong |
|---|---|
schema | the shape of the document |
flow-lint | links between steps and fields |
path is a JSON Pointer to the node that breaks the rule: /flow/steps/confirm, /submission/properties/appointment. Status is 200 in both outcomes; valid is the verdict. Nothing is stored. Every rule and its message: writing a config. Declaration-to-input mapping: widget catalogue.
4–5. Publish with the owner's token
The owner copies the token from the console — their business page, "Connect an AI agent". An owner without an account signs up at https://console.mindthefront.com/#agent, confirms their email from the link we send, and lands on that screen. Don't create the account yourself: the account appears only once the owner confirms the email. The token is a secret: keep it out of the repository, out of committed files and out of anything you print back.
BUSINESS=$(curl -s https://console.mindthefront.com/api/businesses/current -H "X-Owner-Token: $TOKEN")
ID=$(echo "$BUSINESS" | jq -r .id)
KEY=$(echo "$BUSINESS" | jq -r .publishableKey)
CONFIG=$(curl -sX POST https://console.mindthefront.com/api/businesses/$ID/configs \
-H "X-Owner-Token: $TOKEN" -H 'Content-Type: application/json' \
--data @config.json | jq -r .id)
curl -X POST https://console.mindthefront.com/api/configs/$CONFIG/publish -H "X-Owner-Token: $TOKEN"
"Issue a new one" in the console replaces the token: the previous one gets 401 at once, the embedded widget keeps running on the same publishable key.
6. Embed
Put the snippet on the page with $KEY as publishableKey.
Constraints to design around
| Constraint | Consequence for you |
|---|---|
| No model call at runtime | anything the visitor is asked must exist as a step in the config |
timeZone is required on an appointment field | the IANA zone where the business operates; ask the owner when the location does not settle it |
Regeneration in the console rewrites flow | key anything you build on submission field names, not step ids |
additionalProperties must be false | the server applies your schema exactly; it adds nothing |
The plan limits requests, and the widget gets 402 and does not show once they run out | read GET /api/businesses/$ID/plan: widget.reason says why; tell the owner instead of republishing |
| The plan limits config generations in the console | writing the config yourself, as on this page, spends none |