Security & reliability

Why this page exists

Choosing a form provider means trusting someone else with visitor data. This document explains what we protect by design, what is public by necessity (and why that is normal), and what you should still do on your website and integrations. It is meant to answer security questions from developers, founders, and compliance-minded teammates — not to replace your legal agreements.

Encryption and transport security

Form submission endpoints accept traffic only over HTTPS. That means the HTTP body (field names and values) is encrypted between the visitor's browser (or your server-side client) and FormTo's infrastructure, using standard TLS as negotiated by modern clients.

For static sites and Jamstack frontends, this matters because you are not required to terminate TLS or manage certificates on your hosting provider just to receive form posts — FormTo handles the secure ingestion endpoint for you.

Your marketing site should also be served over HTTPS so visitors are not downgraded on the way to your pages; that is separate from FormTo but is part of a sensible overall setup.

Understanding the public form URL

Each form has a public URL that accepts POST requests without a browser login. That is how HTML forms and simple JavaScript clients work everywhere on the web — contact forms, waitlists, and lead capture are intentionally unauthenticated on submit.

What this means in practice:

• Anyone who knows or guesses the endpoint could send requests to it. We mitigate noise with rate limits, spam controls, and monitoring — see below.
• Treat every field as untrusted user input when you display it in the dashboard, in email, or in downstream systems (escape or sanitize for HTML contexts, same as any user-generated content).
• Do not put secrets in form fields or hidden inputs (API keys, internal tokens, passwords). Public forms are not a vault.

This model is the same class of design as other form backends and many "serverless form" products: the security story is about transport, abuse handling, and strong access control on the owner side — not about hiding the endpoint URL as a secret.

Your account, sessions, and API keys

Access to the FormTo dashboard — where submissions, settings, exports, and webhooks are managed — goes through Clerk for authentication. You sign in with your identity provider flow; we do not operate a separate password database for that layer in this product surface.

On Professional, Business, and Enterprise plans, programmatic access uses API keys you create in the app. Treat them like passwords: store them in environment variables or a secrets manager, never commit them to git, and never embed them in frontend bundles or public repositories. Rotate or revoke a key immediately if it leaks.

Full API route details are in Documentation.

Data handling, retention, and portability

Submissions are stored so you can work with them in the product: search, review, and export. You are not locked into only viewing data in our UI — CSV export and webhooks let you copy each event into databases, queues, or tools you operate, under retention rules you define there.

For legal retention, erasure, and subprocessors, your contract and privacy materials are the source of truth — start with Privacy and Terms, and contact us if you need a vendor questionnaire answered.

Spam, bots, and rate limits

Public endpoints are scanned and abused across the internet. FormTo applies layered defenses: honeypot fields, timing signals, and (on paid tiers) stronger filtering than the Free plan. Exact capabilities per plan are listed on Pricing.

We also apply rate limiting scoped to IP and endpoint so burst traffic cannot overwhelm your form or the platform. If you see 429 responses during legitimate spikes, slow down retries or contact us about higher-volume patterns.

Integration details (field names to leave empty, optional _formto_ts): Spam & honeypots in the docs.

Webhooks and email delivery

Webhooks: configure an HTTPS URL in the dashboard. We log delivery attempts so failures are visible, and failed deliveries can be retried — you are not left guessing whether an event vanished. Point webhooks at HTTPS endpoints you control; validate payloads in your handler the same way you would for any inbound HTTP API (schema checks, idempotency where needed).

Email notifications:you edit templates and what is sent, which supports consistent branding and internal review ("what exactly goes to the team inbox?").

Uptime, monitoring, and incident awareness

We target reliable ingestion for production forms. Public status and incident communication live on Status. For automated checks, the API exposes GET /health (docs).

What we do not claim

No hosted service can promise "zero risk." We do not ask you to trust a black box: the model above is standard for form SaaS — TLS to us, strong auth for operators, abuse controls on public POSTs, and clear observability for webhooks. If your threat model requires air-gapped infrastructure or exclusive on-prem processing, a self-hosted stack may be a better fit; for typical marketing and contact forms on HTTPS sites, FormTo is designed to be a responsible default.

Report a security issue

If you believe you have found a vulnerability in FormTo, email contact@formto.dev with steps to reproduce and, if possible, non-destructive proof. We take reports seriously and will work with you on a coordinated fix. General security questions are welcome through Contact.

This page describes our security posture in plain language and is not a legal agreement, certification, or warranty. Privacy practices and contractual terms are in Privacy and Terms.

← Home