Field Types

Krafter Forms supports all standard HTML input types and provides a visual form builder in the dashboard. This page covers supported field types, special fields, and how to use the form builder.

Supported Input Types

The following HTML input types are supported as form fields:

Type	HTML Element	Description
text	<input type="text">	Single-line text input
email	<input type="email">	Email address with validation
textarea	<textarea>	Multi-line text input
number	<input type="number">	Numeric input
tel	<input type="tel">	Telephone number
url	<input type="url">	URL with validation
select	<select>	Dropdown selection
hidden	<input type="hidden">	Hidden value (not shown to user)
date	<input type="date">	Date picker

checkbox and radio are not field types

This table used to list them; the API rejects both with a 422. That is a limitation of the field definition only — the public endpoint accepts any field name, so a checkbox or radio group in your own HTML is submitted and stored like anything else. You just cannot declare one in the form builder.

TIP

You do not need to define fields in advance. The public endpoint accepts any field name. Defining fields is optional and used for the form builder and HTML snippet generation — and, if you opt in, for server-side validation.

Form Builder

The dashboard includes a visual form builder for configuring fields without writing HTML.

Features

• Add fields -- Select a field type and give it a name and label
• Remove fields -- Delete fields you no longer need
• Reorder fields -- Drag and drop to change field order
• Configure options -- Set required, placeholder, and default values
• Select/radio options -- Define the list of options for dropdown and radio fields

HTML Snippet Generation

Once you have configured your fields in the builder, click HTML Snippet to generate a ready-to-use HTML form. The generated snippet includes:

• Correct action and method attributes
• All configured fields with labels and attributes
• A honeypot field for spam protection
• A submit button

You can copy the snippet directly into your website.

Special Fields

Field names prefixed with _ (underscore) have special behavior and are not stored as part of the submission data.

_honeypot / _gotcha

Hidden fields for spam detection. If a bot fills in these fields, the submission is flagged as spam.

<!-- CSS-hidden honeypot field -->
<div style="position: absolute; left: -9999px;">
  <input type="text" name="_honeypot" tabindex="-1" autocomplete="off">
</div>

See Spam Protection for details.

_redirect

URL to redirect the user to after a successful submission. Only used for HTML form submissions (not JSON).

<input type="hidden" name="_redirect" value="https://yoursite.com/thank-you">

_subject

Override the default email notification subject line. The default subject is "New submission: {form name}".

<input type="hidden" name="_subject" value="New contact request">

_replyto

Specify the form field name whose value should be used as the reply-to address in notification emails. This is the field name, not the email address itself.

<!-- When the user fills in the "email" field, that value becomes the reply-to address -->
<input type="hidden" name="_replyto" value="email">

_cc

Comma-separated list of additional email addresses to CC on notification emails.

<input type="hidden" name="_cc" value="manager@company.com,support@company.com">

Automatically Stripped Fields

The following fields are automatically stripped from submission data and are never stored:

Field	Purpose
_csrf_token	Phoenix/Rails CSRF tokens
_utf8	UTF-8 encoding markers

Example: Full HTML Form

Here is a complete example using multiple field types and special fields:

<form action="https://app.krafter.dev/f/contact" method="POST">
  <!-- Honeypot (hidden from real users) -->
  <div style="position: absolute; left: -9999px;">
    <input type="text" name="_honeypot" tabindex="-1" autocomplete="off">
  </div>

  <!-- Redirect after submission -->
  <input type="hidden" name="_redirect" value="https://yoursite.com/thank-you">

  <!-- Custom notification subject -->
  <input type="hidden" name="_subject" value="New contact request">

  <!-- Use the email field as reply-to -->
  <input type="hidden" name="_replyto" value="email">

  <!-- Visible fields -->
  <label for="name">Name</label>
  <input type="text" id="name" name="name" required>

  <label for="email">Email</label>
  <input type="email" id="email" name="email" required>

  <label for="phone">Phone</label>
  <input type="tel" id="phone" name="phone">

  <label for="subject">Subject</label>
  <select id="subject" name="subject">
    <option value="general">General Inquiry</option>
    <option value="support">Support</option>
    <option value="sales">Sales</option>
  </select>

  <label for="message">Message</label>
  <textarea id="message" name="message" required></textarea>

  <label>
    <input type="checkbox" name="newsletter" value="yes">
    Subscribe to newsletter
  </label>

  <button type="submit">Send</button>
</form>

Server-Side Validation

Marking a field required puts a required attribute on the generated HTML snippet, which the browser enforces. Nothing else did: a curl post, a bot, or any client that skips the browser could store a submission with every required field empty.

Set settings.validate_required_fields to have the server check too:

curl -X PATCH https://app.krafter.dev/api/v1/forms/FORM_ID \
  -H "Authorization: Bearer kr_live_abc123def456" \
  -H "Content-Type: application/json" \
  -d '{"settings": {"validate_required_fields": true}}'

With it on, a submission missing any field declared required is rejected and nothing is stored:

// 422 Unprocessable Entity
{
  "error": "missing_required_fields",
  "fields": ["email", "phone"]
}

A field that arrives empty ("", whitespace, or an empty list) counts as missing, not as present.

Two behaviours worth knowing before you switch it on:

• Submissions flagged as spam are never rejected this way. They keep getting the same 201 every flagged submission gets, so a bot cannot use the error to confirm it found a real form or to read your field names back.
• The 422 is a JSON body, not a redirect. A browser posting a form with _redirect set will land on that JSON rather than your thank-you page when a required field is missing. Keep the required attributes in your HTML so the browser catches it first; this check is the backstop for clients that skip them.

Off by default, on purpose

Turning this on for every form would start rejecting submissions that forms accept today — a contact form quietly dropping leads is worse than the gap it closes. Check your existing submissions for incomplete rows before enabling it on a live form.

The flag must be a real boolean. "validate_required_fields": "true" (a string) is rejected with a 422 rather than silently reading as false.