Add a working contact form to a static site in 2 minutes

A static site cannot receive a form submission on its own; it needs somewhere to send it. With Birta you describe the form to your agent, the fields you want, and it declares the form and writes the markup. From then on every submission lands in your project's panel, and a summary email follows within 15 minutes.

This walks through the real contract behind that: what your agent writes, where a submission goes, and what Birta does not do, so you are not left guessing.

Why a static site can't just "have" a form

A plain HTML form is front-end markup. When someone clicks submit the browser sends that data somewhere, and a static site has no back end to catch it, because a static host serves files and processes nothing.

This is the wall almost everyone hits first. You build a landing page with an AI tool, it looks finished, and a <form> tag sits there expecting the submit button to work. It does not, because nothing is listening.

That is not a bug in your markup. It is the nature of static hosting: fast, cheap and hard to break into precisely because no server-side code is running. The tradeoff is that a form needs one more piece, something that accepts the request and does something with it.

What "add a form" actually means here

On Birta that piece is built in, though not as a drop-in widget. Tell the agent already building your site what you want to collect, a name, an email, a message, a consent checkbox, and it declares the form on your project: a set of fields, each with a type and whether it is required.

Then the agent writes the markup itself, styled to match your site. Birta gives no ready-made form block and does not dictate how the form looks. When the form is the whole point of the page, how to make a landing page builds it and the offer around it in one pass.

That is a deliberate difference from widget tools such as Formbricks, which embeds its own form in an iframe. The box works and it looks like the tool rather than your site. Here the HTML is yours, and so is the "thanks for reaching out" line the visitor reads. The operational reference is the lead-forms guide.

Where a submission actually goes

This is the part most guides skip, and it decides whether the form works. A submission posts to POST /_forms/<key> on the site's own host, whatever address it is live at. The body is JSON and the endpoint is public: no API key, no project id, no secret token belongs in the markup, because the visitor's own browser is sending it.

A successful submission gets 201 {"status": "accepted"}. A rejected one comes back with a specific code: 400 when a field does not match the declared form, 403 on a draft, because a version preview never accepts a submission, 404 for an unknown form key, 413 when the payload is too large, 429 past a rate limit. Your agent turns that code into whatever the visitor should see next. Birta does not write that message for you.

The body carries only the keys you declared. An absent field, null, an empty string and an empty list all count as not filled in: a required field left that way is refused, an optional one is left out of the lead with no error.

One field is stricter than it looks. A consent field takes a JSON boolean, and only true counts as given. Anything else, including the string "true" instead of the boolean, is refused as consent_not_given. A checkbox any truthy-looking value could satisfy is not really consent.

What you can actually collect

A form can hold up to 20 fields, and a project can declare up to 5 forms, splitting an order form from a callback request, say. Each field is one of a handful of types: short text, long text, email, a single choice from a list, a checkbox for consent. Short text tops out at 500 characters, long text at 5,000, email addresses at 254, and a whole submission at 65,536 bytes.

Those are this deployment's configured limits as of publishing, not a number carved into the product forever. What matters is the shape: room for a real inquiry, not enough for someone to paste in a novel.

Reading what comes in

Every accepted submission shows up in your project's panel marked "new," with the date, the form it came from and every field the visitor filled in. Expect some of it to be nothing: across 707 measured forms, 17% of submissions were spam. A site collecting more than one kind of request, an order form and a callback form, splits them out so you are not scanning one long list.

You do not have to refresh it. The notification is an email rather than a live push: a submission opens a 15-minute window, and when it closes one message goes to everyone with access, naming the project and listing every submission that landed, each with its form, time and fields. A single late submission still gets its own email 15 minutes after it arrives.

When the form sits on a page built to collect inquiries, how many leads your plan lets you open starts to matter as much as the form. When there is nothing to reply to yet, the form shrinks to one field and the job becomes collecting a waitlist. And on a site of several pages, the link to the form usually belongs in the footer, the one block a visitor can reach from wherever they gave up.

And this is where it stops

Three things this isn't. No Telegram delivery, no webhook, and no choice of where a submission goes: it lands in the panel, and a digest follows by email, and that's the whole delivery story. There's also no accept-payment step built into the form.

If your project needs any of that today, it needs a different layer than this brick gives you.

Keeping spam out without a CAPTCHA

Birta doesn't put a CAPTCHA in front of your form. A plain rate limit does the work instead. A visitor can send up to 5 submissions in a 10-minute window, and a project accepts up to 200 submissions an hour in total. Past either limit, a submission comes back as 429 too_many_submissions, and your agent can turn that into a line on the page.

That's not smart spam filtering. It won't recognize a script pacing itself under the limit, and it won't score a message for spammy content. What it actually stops is the ordinary case: a double-submitted form, a broken retry loop, someone hammering refresh. For most contact forms, that covers most of what goes wrong.

Common questions