Form Backend Tool FAQ

A hosted form backend: you point a website form at the endpoint it gives you, and submissions are stored in a dashboard and emailed to you, with no server of your own to run. The fuller explanation is What Is a Form Backend?

Developers with static or frontend-only websites, freelancers and agencies delivering client sites, and small businesses that need website inquiries without maintaining a backend.

No, not for receiving form submissions. Receiving, checking, storing and notifying are the service's job. Your website only needs the form itself.

Yes, that is the primary case. A plain HTML form posts directly to the endpoint. See the static websites guide.

Yes, either as a plain form element or with fetch and submission state, as the React guide shows. No package is involved.

Yes. A form in a Server Component can post directly, and a small client component can use fetch. You do not need an API route for this, as the Next.js guide explains.

No. There is no SDK. The integration is an HTTPS endpoint that any form or HTTP client can post to.

Set the form's action to your form's endpoint, its method to POST, and give every field a name. The tutorial walks through it step by step, and the HTML reference collects the details.

Yes. POST JSON with Accept: application/json and the endpoint answers in JSON: {"ok": true, "message": "Submission received."} on success, or an error object with a status code. The docs example shows the exact format.

The endpoint accepts POST only. A form without a method defaults to GET, which is refused with 405. POST is also the correct method for sending form data.

The name is how a field is identified and labelled. A field without one is not sent, so it never reaches your dashboard or email. With a hand-built JSON payload, the object keys play the same role.

Yes, with the hidden _redirect field set to a complete http:// or https:// URL, usually a thank-you page on your own site. Without it, visitors see a simple built-in thank-you page. In fetch mode there is no redirect; your code decides what happens next.

A hidden trap field. Real visitors never see or fill it; bots that complete every field give themselves away. Submissions with a filled _honey are flagged as spam in your dashboard and are not emailed to you.

Yes. Keep your markup and field names, change the action and method, and add the two hidden fields. The HTML reference has the checklist.

No. Both browser options post directly to the endpoint. A route or action of your own is only worth adding when you need your own server-side work at submit time.

With the service, against the form they were sent to. They are stored before any notification is sent, so a notification problem can never lose a submission.

Yes. Each form has its submissions list in your dashboard: open a submission, mark it read or unread, filter the list, review spam separately, delete entries and export to CSV.

Yes. Every non-spam submission is emailed to the notification address set on the form. That address must be verified once before notifications are delivered to it.

Nothing is lost. Because the submission is stored first, it stays in your dashboard even if an email cannot be delivered. The stored copy is the record; the email is the alert.

Two layers: the _honey honeypot described above, and a rate limit of 10 submissions per 60 seconds per form per visitor. Flagged submissions are kept in the dashboard marked as spam and are not emailed.

Yes, on the Pro and Agency plans, as an additional channel alongside email. You verify your WhatsApp number in the form's settings once, and new submissions then also arrive as a WhatsApp alert.

Per form, per calendar month: 250 on Free, 2,500 on Pro and 10,000 on Agency. A Free account holds up to 3 forms; Pro and Agency place no cap on the number of forms. The docs limits section is the authoritative list.

At most 25 KB per submission, up to 50 fields, field names up to 100 characters, values up to 5,000 characters, and 10 submissions per 60 seconds per form per visitor.

No. File inputs do not break a form, but the files themselves are ignored and only text values are stored. Forms that must receive files need a different tool.

No. Submissions are not pushed to other systems. Delivery is the dashboard, email, CSV export, and WhatsApp alerts on paid plans.

No. The service does not send an automatic reply email to your visitor. Their confirmation is your thank-you page, or your own client-side confirmation in fetch mode.

No. Submissions are stored, listed and exportable, but there are no pipelines, contacts management or automatic syncing into other software.

No. A form can collect an appointment or information request, including a preferred date or time the visitor types in, but there is no calendar, availability checking or automatic confirmation. You reply and confirm yourself.

No. Forms collect messages and inquiries; they cannot charge a visitor or manage orders.

No. There is no white-label dashboard, custom domain for the dashboard, or client-facing branding option.

No. An account is a single login holding its forms. The freelancer and agency page describes the two working models this allows.

Up to 3 forms, 250 submissions per form per month, email notifications, the dashboard with read/unread and delete, spam protection and CSV export. No credit card is needed. The live comparison is in the pricing section.

Pro ($12 per month) raises the quota to 2,500 submissions per form per month, removes the cap on the number of forms and adds WhatsApp notifications. Agency ($35 per month) raises the quota to 10,000 per form per month and is positioned for running forms across multiple sites.

Plans are billed monthly per account through Paddle. You can cancel at any time; the paid plan stays active until the end of the current period and the account then returns to the Free limits.

Yes. A full refund is available within 14 days of an initial purchase and within 14 days of any renewal charge. The details are on the refund policy page.

No, and it is not meant to be. As the docs security guidance puts it, the key is public by design: it appears in your page like any form action URL. It only lets people submit to that one form. It cannot read submissions or change settings.

Only your signed-in account. The dashboard checks your session, and one account can never see another account's forms or submissions.

Forms post to an HTTPS endpoint; abuse is limited by the rate limit and the honeypot; notifications go only to verified addresses. No broader compliance or certification claims are made, and the privacy policy describes how data is handled.

When your website is static or frontend only, your forms exist to start conversations (contact, quote, inquiry, lead), you reply personally, and your volume fits the plan quotas. That covers most small business and client websites.

When a form must store uploaded files, push submissions into other systems automatically, send automatic replies, handle payments or bookings, or run inside an application with its own accounts and logic. Those are real backend jobs, and the concept article explains where the line sits.