Oleg Isonen
99371187dc
## Summary - move the complete GitBook documentation tree and assets into Builder under `/docs` - generate the exhaustive MCP page from the local CLI source in the same change - publish GitBook from a release-gated `docs` branch containing the exact successfully released revision - run MCP documentation tests, typechecking, and stale-output checks with the existing generated-docs check - remove links to the Community Discussions repository ## Technical choices - Import the current documentation as a linear snapshot so the branch satisfies Builder's required-linear-history protection. - Keep the Markdown wrapper separate from the TypeScript generator at `scripts/docs/mcp-page.md`. - Generate through `packages/cli/local.js` so CLI guidance and its documentation are reviewed together. - Let `check:generated-docs` reject CLI changes that leave the committed MCP page stale. - After both GitHub release creation and package publication succeed, fast-forward the read-only `docs` branch to the immutable release tag commit. A divergent update fails instead of publishing a different revision. - Configure GitBook to publish `/docs` from the `docs` branch, not directly from `main`. - Exclude `/docs` from the repository-wide `oxfmt` scan so imported GitBook Markdown retains its established formatting; generator tests and stale-output checks still validate the MCP page. - Exclude `transcripts/` and GitHub Discussions from the migration. ## Todo - [x] Import documentation, navigation, includes, and assets under `/docs`. - [x] Generate the MCP page from the local CLI source. - [x] Move MCP generation and validation into Builder. - [x] Require MCP documentation updates alongside CLI changes. - [x] Publish released revisions through a read-only `docs` branch. - [x] Remove Community repository links from Builder and the migrated docs. - [x] Preserve and verify a final Community Git bundle locally. - [ ] Merge this pull request. - [ ] Let the next successful release create or advance the `docs` branch. - [ ] Repoint GitBook Git Sync to `webstudio-is/webstudio`, branch `docs`, root directory `/docs`. - [ ] Verify `docs.webstudio.is`, navigation, assets, anchors, and the MCP page in production. - [ ] Delete `webstudio-is/webstudio-community`. ## Verification - `pnpm check:generated-docs` - `pnpm lint` - `pnpm oxfmt --check` - `git diff --check origin/main...HEAD` - generator regression test demonstrated failing when the GitBook wrapper behavior was removed, then passing after restoration - no fixture inputs or outputs are affected ## Known limitation All documentation merged after the previous release waits for the next successful release before GitBook publishes it. This deliberately keeps the public MCP reference aligned with an installable CLI revision. Ref #5986
4.7 KiB
description
| description |
|---|
| Webhook Forms enable form submissions to get sent to an email address and optionally third-party services like Airtable, n8n, or Zapier. |
✍️ Webhook Form
{% hint style="info" %} Name change: Webhook Forms used to be called "Forms." However, Forms are now a different component intended for building searches and filters. {% endhint %}
{% embed url="https://www.youtube.com/watch?v=eE-CkewQHMs" %}
Receiving Form Submissions
Webhook Forms are used when you need to send form submission data to an external service, rather than modifying page content like searches and filters.
Email Notifications
By default, submissions are sent to the Project owner.
{% hint style="info" %} Pro feature: You can customize the recipient of email notifications by navigating to Project settings > General.
{% endhint %}
Webhooks
You can also send form submission data to a webhook—an external URL that receives the data and triggers an action, such as adding a contact to an email automation platform.
- Obtain a webhook URL from a third-party platform such as Airtable.
- Paste the URL into the
Actionfield in Webhook Form > Settings.
Once set up, every form submission will send a payload (form fields and values) to the webhook URL.
Using the Webhook Form Component
You can add a Webhook Form Component to your canvas from Components Panel > Data section.
{% hint style="warning" %} Webhook Forms do not submit inside the Builder, including in Preview. They only submit on the published site. {% endhint %}
Webhook Form Structure
A Webhook Form consists of three nested instances:
- Form Content – The primary form fields.
- Success Message – Displayed upon successful submission.
- Error Message – Shown when an error occurs.
You can add new Components to further expand and modify your form.
Form States
Webhook Forms automatically switch between states based on submission results.
Success Message
When a submission is successful, users will see a success message. To customize it:
- Select the main "Form" instance and go to Settings.
- Change the State from "Initial" to "Success."
- Edit the success message directly on the canvas.
Error Message
If there’s an error during submission, users will see an error message. To modify it:
- Select the Webhook Form Component.
- Set the State to "Error" to preview and edit the error message.
Form Inputs
{% hint style="warning" %}
Each input field must have a name attribute for its data to appear in email notifications and webhook payloads.
{% endhint %}
Ensure every form input has a value for the name field to be included in submissions.
For a full list of input types, including checkboxes and radio buttons, refer to Form Inputs.
Input Properties
Each input field has several configurable properties in Settings:
- Name: The field identifier used in submissions (required for data to appear)
- Type: Define the input type (text, email, tel, etc.). Setting type to "email" enforces email format validation.
- Placeholder: Hint text shown inside the input before user enters data (e.g., "john@doe.com")
- Required: When enabled, the form cannot be submitted without this field
- Autofocus: When enabled, this field is automatically focused when the page loads
Styling Form States
You can create interactive form styling using states in the Style panel:
- Hover: Apply styles when users hover over an input (e.g., wider border, box shadow)
- Focus: Apply styles when an input is active/selected (e.g., colored border, glow effect)
- Placeholder: Style the placeholder text appearance
To apply state-specific styles, select the input element, open the state dropdown in the Style panel, and choose the state you want to customize.
Bot Protection
Webstudio forms include built-in bot protection to prevent spam submissions. This protection works automatically without requiring any additional configuration – no CAPTCHAs needed. The system analyzes submission patterns to distinguish between legitimate users and automated bots.
Related
- Form – Standard HTML forms
- Input – Text input fields
- Button – Submit buttons
- n8n Integration – Automate form workflows
- Zapier Integration – Connect to other apps