How it works

MakeTheForm is one HTTP endpoint per form. Your page sends a POST to https://mtform.co/f/your-form-key, we check it, store it, and answer. Email, webhooks and every other destination happen afterwards, from a queue, so a slow mail provider never slows down the person pressing Submit.

There is no SDK and nothing runs on your site. The form key in the URL is an address, not a credential: it lets anyone submit to the form and lets nobody read from it.

Everything you create sits in three levels.

Archiving a project takes it out of the project switcher but keeps its forms accepting submissions, so tidying up never breaks a live site. See Projects for clients and Team.

Checks run cheapest first, so abuse is turned away before it costs anything. The rate limit runs before the quota check, so a flood cannot spend your allowance.

1. Find the form by its key. An unknown or retired key is a 404.
2. Check the form is not paused and the workspace is active.
3. Rate limit per IP address and form: 5 requests in 30 seconds, 30 in 10 minutes.
4. Origin policy, when the form is restricted to its allowed domains.
5. Content type and size limits, then parsing.
6. Split out the reserved control fields, such as the honeypot and the redirect target, so they are never stored as your data.
7. The honeypot, your own block rules and, if you turned it on, the disposable email check.
8. The Turnstile challenge, verified on our side, if the form uses one.
9. Validation: a submission with no fields at all is refused.
10. Content scoring from 0 to 100. Likely spam is kept in the Spam view; near-certain spam is refused and does not count against your quota.
11. Duplicate check: the same submission from the same visitor within a minute is not stored twice.
12. Quota check.
13. Store the submission and its delivery jobs in one database transaction.

The last step writes the submission and one queue entry per destination (email, each webhook, Slack and so on) in the same transaction. Either both exist or neither does, so a success response always means the submission is in your dashboard and every delivery is queued. Nothing after that point can turn it back into an error.

A separate worker picks up the queue and delivers. When a destination fails with something temporary, it tries again on this schedule:

After the sixth attempt the job stops rather than retrying forever. A permanent failure, such as a mailbox that does not exist, stops at once, because retrying a hard bounce damages deliverability for everyone.

Submissions held in the Spam view are stored but not delivered anywhere. On the Free plan, notification email is sent as one daily digest instead of one message per submission; storage, the dashboard and webhooks are unaffected. See Email notifications.

The endpoint answers a browser and a script differently. It decides from the request headers, never from the user agent.

The 303 means the browser lands on a normal page with a GET, so refreshing it cannot send the form again. The full response shapes and error codes are in the API reference.