FreelyForm

Changelog

What changed, and when.

Release notes for the service itself. Each entry lists only what is live; nothing here is a plan. The machine-readable version of the current behaviour is at /facts.json.

Last reviewed 2026-11-12.

0.1.0 ·

Pricing ladder, over-limit protection, usage notices and operator tools

The largest single day of change so far: five published tiers with a monthly/annual switch, submissions that are held rather than rejected when an account runs out of allowance, usage warnings at four thresholds, and command-line tools for suspending a form or account.

  • New Five plans (Free, Personal, Professional, Business, Custom) with a monthly/annual switch showing the per-month equivalent of the yearly price.
  • New Tier-aware entitlements: file uploads from Personal, rules and signed webhooks from Professional, your own sending domain and the deliverability view from Business.
  • New Over-limit handling: submissions keep arriving and are stored as “over limit” with no notification, and can be reprocessed once there is room. Visitors are never rejected because of the account quota.
  • New Usage notices at 50%, 75%, 90% and 100% of the monthly allowance, once each per period.
  • New Operator commands for suspending or resuming an account or a form, listing flagged accounts, and marking an account for review.
  • New Free-account ceiling: three accounts per client IP in thirty days, lifted entirely when a paid account exists on the same IP.
  • New Machine-readable factsheet at /facts.json and /facts, generated from the running configuration rather than written by hand.
  • New Glossary of 28 terms, and a single-file corpus at /llms-full.txt carrying every canonical answer.
  • New Five long-form guides on static-site form handling, one per platform family and one covering validation, storage, delivery and observability.
  • Changed A form is now five tabs — Integration, Submissions, Settings, Workflow and Rules — instead of one long page. Each one holds a single job, and the old /edit address redirects to Settings.
  • Changed Creating a form now takes one optional name and a confirmed destination: the other seventeen settings are behind an “Advanced settings” disclosure.
  • Changed Confirming the account email now also confirms it as a notification recipient, so no second confirmation email is needed for your own address.
  • Changed Submission and sign-up rate limits key on the real client address rather than the proxy hop.
  • Fixed Newly created forms no longer default to captcha, which had been rejecting every plain HTML post with turnstile_required.
  • Removed A stray “replay from the log” label that survived earlier copy audits because it lived inside an SVG diagram.

0.0.9 ·

Public launch, email delivery and inbound mail

The service went live on its own domain: Cloudflare in front, a reverse proxy on the origin, transactional email through Resend, and inbound mail routed to a support inbox.

  • New Public endpoints: form submission, management API, dashboard, and the library knowledge base.
  • New Transactional email with per-delivery records, retries and a suppression list that survives hard bounces and complaints.
  • New Signed webhooks to HTTP endpoints, Discord and Telegram, with retries, a delivery log and replay.
  • Fixed Bounce handling: a column type mismatch meant real bounces returned an error and suppression was never written.

How releases are written

  • An entry appears here when the change is deployed, not when it is designed.
  • Breaking changes to the endpoint contract are called out explicitly, with what to change on your side.
  • Limits are not restated here — they live in the factsheet, which is generated from the running configuration, so a limit change shows up there without a hand-edited note.
  • The internal repository copy of the changelog additionally records file paths and verification steps; this page exists for people who use the service rather than maintain it.

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

One action attribute · urlencoded, JSON, or multipart · no SDK, no build step