Deftform Changelog

You can now connect AI assistants like Claude Code, Claude Desktop, Cursor or VS Code to your Deftform workspace with the new MCP server (Model Context Protocol). Ask your assistant in plain language to create forms, add and arrange fields, change settings or look at your responses, and it does the work in your workspace. ChatGPT and the claude.ai website aren't supported yet, as they require signing in via OAuth instead of using an API token.

What your assistant can do

• Build forms from scratch. Create a form and add up to 50 fields in one go, including short and long text, email, phone, number, date, dropdowns, single and multiple choice, ranking, rating, slider, time picker, address, file upload, eSignature, opt-in checkbox, hidden fields, paragraphs, dividers, spacers and page breaks.
• Edit existing forms. Update labels, options, placeholders, help texts, required status and other field settings. It can also delete fields, reorder them, or insert new fields at a specific position.
• Manage form settings. Close or reopen forms, change the submit button label, completion message, notification emails, SEO settings and more.
• Work with responses. List and filter responses, open single responses, download response PDFs, and get statistics such as response counts, conversion rates, trends and answer distributions.
• Submit responses to your forms, for example to import data or test a form.

Built with safety in mind

• Content written by your assistant is cleaned before it's saved. Labels and options are stored as plain text, and paragraph and consent texts only allow basic formatting and safe links.
• HTML/code, image and embed elements can only be added in the form builder.
• Deleting a field is marked as a destructive action, so your MCP client can ask you for confirmation first.
• Your assistant only ever sees the workspace that the token belongs to.

Getting started

Go to Settings → API + MCP, create a token and add the server to your MCP client:

{
  "mcpServers": {
    "deftform": {
      "type": "http",
      "url": "https://deftform.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

Read our help center article to learn more.

Read-only and read & write tokens

When you create an API token, you now choose its access level:

• Read-only access: view forms, fields and responses. This is the new default and a good fit for reporting or for trying out AI assistants.
• Read & write access: also create and change forms, fields and settings, and submit responses.

The token list shows the access level of each token. Your existing tokens keep full access, so current integrations keep working. With a read-only token, MCP tools that change data aren't offered to your assistant, and API requests that change data return 403 Forbidden.

API: manage form fields

Everything the MCP server can do with fields is now also available in the REST API:

• POST /forms/{id}/fields adds one or more fields, optionally at a specific position.
• PATCH /forms/{id}/fields/{UUID} updates a field's settings.
• DELETE /forms/{id}/fields/{UUID} deletes a field.
• POST /forms/{id}/fields/order sets the order of all fields.

Form data returned by the API now also includes more field settings, such as the custom key, read-only state, slider, time picker and phone settings, opt-in value and hidden field default. These endpoints need a token with read & write access.

Improvements

• Tightened access checks in the form builder for adding, editing and duplicating fields and for validation rules.

On October 21 and 22, some webhook endpoints received submissions that were weeks or months old, in some cases going back to December 2025. Some of these were incomplete submissions: forms a visitor started but never sent (when this was enabled for the form). They arrived with partial or empty answers and a response number of 0, because incomplete submissions never get a number.

We're sorry for the trouble this caused, especially if it set off emails or automations, or created duplicate records on your side.

Why it happened

We retry webhooks that fail. Some older submissions, including incomplete ones, were still marked as "not delivered". Until now, a flaw in the retry process meant it rarely reached them. While building the new webhook event log, we made the retry process more reliable. As a result, it worked through all of those older submissions at once and sent them to the connected endpoints.

The affected responses also show October 21 as their "Completed" date in the responses list, because marking them as delivered changed that date. Failed webhooks are only retried within 24 hours of the submission, and at most 3 times. Their answers were not changed.

What we changed

• Incomplete submissions are never sent. Only forms that were actually submitted trigger a webhook.
• Retries have a time limit. Failed webhooks are only retried within 24 hours of the submission, and at most 3 times.
• Old submissions are never sent automatically. Anything older than 24 hours is no longer delivered on its own, even if you connect a new endpoint to the form.
• No more duplicate sends. Two retry runs can no longer overlap, and the automatic process never sends a submission twice to the same endpoint.
• "Completed" dates stay unchanged. Marking a response as delivered no longer changes the date shown in your responses list.

You can still resend any event yourself from the webhook event log under Settings → Notifications / Connections → View events. Every webhook sent in the last 30 days is listed there, including the ones from this incident.

You can now see every webhook Deftform has sent, or tried to send, to your endpoints over the last 30 days.

What's new

• Event list per endpoint. Go to Settings → Notifications / Connections and click the new "View events" icon next to an endpoint. You can filter the list by succeeded or failed events.
• Event details. Click an event to open the details panel. It shows:
  • the exact JSON payload that was sent, with a copy button
  • every delivery attempt with its status code, how long it took and what triggered it (initial delivery, automatic retry or manual resend)
  • the response headers and body your endpoint returned, or the connection error if it couldn't be reached
• Manual resend. Click "Resend" to deliver an event again straight away. It sends the original payload, signed with your current webhook secret, and the result appears in the panel immediately. A successful resend also clears the endpoint's error state.

Improvements

• Timeouts and connection errors are now recorded as failed attempts instead of going unreported.
• Automatic retries now send the same payload as the first delivery, including number, number_formatted and referrer.
• The failure alert email now shows the most recent error.

Webhook events are deleted automatically after 30 days.

Today's update includes German translation, bug fixes and maintenance updates.

Hallo aus Deutschland

Since we're based in Germany, many customers have asked us why Deftform isn't available in German. Initially, we made a personal decision to offer all our products only in English. However, the more we received these inquiries, the clearer it became that addressing this priority was necessary.

We are happy to announce that Deftform is now available in German. This update includes most of the marking pages and the log-in area. Existing customers can switch the language in their account settings.

This update will also pave the way for additional languages, as we now have the codebase ready for it. We'll just need to determine which language would be a good fit next.

Bug fixes worth mentioning

We also fixed a dozen small-ish bugs. Worth mentioning are the following:

• Color picker showing black
  A recent maintenance update (about 6 days ago) caused the color picker to always show the color black, even after setting a custom color.
• ⚠️ [BREAKING] Form attachments not always sending
  This issue was a frustrating one, and it took us a while to identify the actual problem. Admins can upload files to a form that are sent to respondents after successfully submitting the form. However, due to various automations running in the background, some of those files were deleted one hour after they were uploaded. As a result, testing this feature would always work initially, but after about an hour, the files could be deleted from storage, while our internal database still had these files on record. The settings would show a linked file that no longer existed. We have now split various background jobs, so this issue cannot happen again. Consequently, files need to be uploaded again, as any reference to the uploaded files was incorrect. We sincerely apologize for this issue.
• Pre-filling "Dropdown" not working
  Using the URL parameter to pre-fill a "Dropdown" element wasn't working correctly. We have restored this functionality.

On September 27, our queues stopped processing background jobs. Our system did not flag any issues and marked the jobs as processing. Unfortunately, that was not the case.

Earlier today, we discovered that background jobs were not being processed at all, which prompted us to restart all queues. Around 1.4 million jobs had accumulated in the queues and are now being processed again. Nothing went missing, and any pending webhook events, emails, AI generations, etc., will be delivered or completed shortly.

We apologize for this incident and are working on a better internal notification system to ensure it does not happen again.

Today, we released a maintenance update and fixed various smaller bugs.

We're currently putting more energy into marketing and plan to release new features and improvements soon. This includes an option to increase the file size that can be uploaded via the "File upload" element, API improvements, additional webhook options and much more.

Webhooks are now cryptographically signed so you can be certain each request genuinely came from Deftform and wasn't tampered with in transit.

What's new

• Every webhook now includes an X-Deftform-Signature-256 header — an HMAC-SHA256 signature of the raw request body, keyed with your workspace's webhook secret.
• You can now rotate your webhook secret anytime from Settings → Connections → Webhook.

Do I need to change anything?
No. The existing secret header is still sent, so current integrations keep working. When you're ready, we recommend switching to signature verification for stronger, tamper-proof security.

Read the guide: Verifying webhooks

Today's update includes 2 bug fixes and new fonts.

We resolved an issue in Google Chrome where interacting with a conditional single choice (radio) or multiple choice (checkbox) field would cause the form to automatically scroll to the top of the page.

We also resolved a custom CSS rendering issue where characters such as `>` were incorrectly converted to their HTML entities, which prevented the applied CSS from functioning as intended.

Additionally, we added two new fonts: Inclusive Sans and Literata.

Today's update is mainly a maintenance update with minor bug fixes and improvements – nothing major.

We also updated the API endpoint /api/v1/responses/{formID} to better distinguish between complete and incomplete submissions.

We added a new is_incomplete attribute to the response, which is either true or false. You can optionally filter the responses and append ?incomplete=false or ?incomplete=true to the endpoint URL to get a filtered response. The change/addition is documented here.

Of course, this only makes sense when the "Track incomplete submissions" toggle is active within the form settings. If it's disabled, is_incomplete will always be false.

Today we released a maintenance update and also a few fixes and improvements. The most notable are mentioned below.

Conditional fields no longer stick around after changing an answer

We fixed a bug affecting forms with chained conditional logic (where a conditional field reveals another field, which reveals another, and so on). Previously, changing an earlier answer could leave a stale field on screen — so both the old and new conditional fields showed at the same time.

Now, when a field is hidden by a selection, any fields that depended on it are hidden too, and their values are no longer saved with the submission.

Multi-page progress bar now shows your position

The progress bar on multi-page forms now reflects which page you're on, rather than tracking completed fields. On landing, you'll see the bar partially filled (e.g. step 1 of 3), giving an immediate sense of how long the form is and how many pages remain — filling completely on the final page.

We also fixed an edge case where pages hidden by conditional logic could throw off the progress calculation; the bar now always matches your actual position through the form.

Form duplication now includes field conditions

Duplicating a form now copies conditional logic along with its fields. Previously, conditions were dropped during duplication, so any fields configured to show/hide based on another field's value lost that behavior in the copy.

Conditions are now remapped to point at the newly created fields, so conditional visibility works immediately in the duplicated form — no need to reconfigure it by hand.

Today's update includes a new "Address" field and some subtle improvements.

New "Address" element

It's now possible to add an address element to your form, which will generate various address-based fields like "Street Address," "City," "Zip Code," and more.

You can enable and disable fields individually to display only the ones important for your needs. Additionally, you can enable autocomplete, allowing visitors to search for their address and have the fields auto-filled.

The new "Address" element is documented here.

Improvements

We also implemented a few minor improvements in the backend. For example, the "Element" selector, which is shown when adding a new field or element to a form, has been restructured.

At some point, we plan to add a search feature as well.

Additionally, we improved the PDF export feature. It will now respect the widths you set for each field. Before the change, all fields in the PDF export were placed in a new row, even when your layout had different sizes for individual fields, such as a 50/50 layout.

Today, we shipped an update to improve accessibility on public-facing forms. We followed general guidelines and best practices and ran tests through multiple tools to ensure no critical issues were left.

Additionally, as a form admin, you now have the ability to add various aria-* attributes such as aria-label, aria-describedby, and more. New field options were added to the general form settings, as well as to each individual field setting.

Please let us know if there was any oversight on our end, and we will gladly make it right.