Receive contact messages without running a customer backend.

Set up the receiver and website together

1. Publish an active static project first.
2. Open the project’s Contact forms and inbox section.
3. Create a receiver with a name and between one and twelve fields. Choose a text or email type, a visible label, required status and maximum length.
4. Copy the HTML form snippet into the website files. The receiver starts disabled and its field schema is fixed after creation.
5. Inspect and publish the updated website, then enable the receiver.
6. Send a test message from the published website and verify that it appears in the workspace inbox.

Field names must match the snippet exactly. Keep names unique and use lowercase letters, numbers and underscores, beginning with a letter. The reserved honeypot field is supplied in the snippet; leave it hidden and empty.

Use native HTML on the same website

The dashboard gives you a relative action for the project’s receiver. Shared platform HTML automatically adjusts that action to its project path. A verified customer-owned domain uses the action at its own root. Use the form on the published website as a normal page, rather than an embedded preview. Do not point an unrelated website at the endpoint. Private previews do not accept contact submissions.

<!-- Copy the real action and fields from your project. -->
<form method="post" action="/__beacon/forms/YOUR_PUBLIC_FORM_ID">
  <label>Email address
    <input type="email" name="email" maxlength="254" required>
  </label>
  <label>Message
    <textarea name="message" maxlength="2000" required></textarea>
  </label>
  <input type="text" name="_beacon_hp" tabindex="-1" autocomplete="off" hidden>
  <button type="submit">Send message</button>
</form>

This example requires a receiver declaring email and message. The normal HTML submission receives an acknowledgement page; invalid input receives an error instead of silently storing a partial message. Style the HTML to match your website and explain how you use submitted information.

Shared sandbox addresses support this native HTML navigation. Their opaque browser origin cannot use JavaScript fetch to submit messages. Same-origin JSON submission requires a normal origin, such as a verified customer-owned custom domain. Private-preview forms are blocked, including attempts to fetch the public receiver from preview JavaScript.

Manage the private inbox

Choose a receiver and switch between active, archived and all messages. Opening a message does not change its read status; use Mark read or Mark unread explicitly. Archive moves a message out of the active inbox and Restore returns it. Archiving is reversible and does not erase visitor information or free storage.

CSV export includes the selected status filter and the declared fields. Keep exports private and handle them according to your own data policies. Viewer accounts, personal API tokens and assistant OAuth connections cannot read or manage contact messages. Management requires an authorized signed-in browser session.

Current limits and failure behavior

The private beta allows five receivers per project and twenty per workspace, including disabled receivers. Each receiver supports up to twelve fields. Text fields allow at most 2,000 characters, email fields at most 254, and a request body at most 16 KiB. Workspace limits are 2,000 stored messages and 500 accepted messages per day. Rate and attempt limits also protect the public endpoint.

A receiver must be enabled on an active published static project to accept messages. A paused or archived website stops capture; its existing inbox remains available to authorized members of an active workspace. Disabling a receiver retains its messages. If a limit is reached, the request is refused; a success acknowledgement means the message was stored. It does not mean an email was sent.

What is and is not supported?

These first-party receivers accept declared plain text and email fields through ordinary URL-encoded HTML forms or same-origin JSON requests. They do not execute customer server code. Files, arbitrary fields, backend proxying, outgoing email delivery and notifications are not supported. There is no field-edit or permanent message-delete flow in this beta; create another receiver when you need a different schema.

Collect only what you need, avoid sensitive documents and credentials, and provide appropriate information to your visitors. The receiver address is intentionally present in public HTML; it is not an account credential or proof of a visitor’s identity. Honeypot and rate controls reduce unwanted submissions without guaranteeing that every message is legitimate. Do not include workspace tokens or passwords in the website’s form.

Explore the product and guides

Access is invitation-only. No payments are collected during the private beta. Sign in to your invited workspace.