Buttons, apps, and forms

A button is the embeddable launcher, an app is one contact action inside it, and a form is a reusable structured input resource. They have independent UUIDs and lifecycle endpoints.

​

Recommended sequence

1. Read the app catalog and its field schemas.
2. Create any reusable form or list.
3. Create an app and link it to the form or list.
4. Create a button with the app UUIDs in display order.
5. Place the returned script source on the website.

Existing script URLs and generated legacy slugs do not change. API v1 adds stable management IDs without changing runtime embed behavior.

​

Agent-readable forms

Form fields use explicit id, type, label, required, and options properties. Agents should present the same labels and constraints to the user and collect only requested information. When AGENT_FORM_SUBMISSIONS_ENABLED=true, a compatible published form advertises a POST submission-request action in the page manifest. The agent sends human_email, answers, requested_by: "agent", and its identity context. Contact Button validates the answers against the live form and emails the human a one-time code. Only confirmation creates the lead and notifies the owner. Captcha, attachment, and unsupported custom fields are deliberately browser-only and advertise human_handoff. Existing browser submissions, callbacks, and integrations are unchanged; the verified agent path is an additive lead channel with a separate rollback flag. Sensitive app fields are write-only. App responses redact fields marked sensitive by the catalog definition.