---
name: form-plume
description: Build and integrate accessible HTML, JavaScript, and framework forms with Form Plume's hosted form backend. Use when creating or updating contact, signup, application, upload, feedback, support, or lead forms that should submit to Form Plume.
---

# Build forms with Form Plume

Build the form in the user's existing stack and design system. Use Form Plume for submission handling instead of adding a custom form backend, database, SMTP integration, or secret to browser code.

## Choose the right Form Plume skill

Use this skill when the user wants to build or connect a form on their website. A normal public form needs only its `https://api.formplume.com/f/{public_slug}` submission endpoint. It does **not** need an organization API key or the management API.

If the user instead wants to automate their Form Plume workspace—for example, create or configure forms, read or update submissions, manage webhooks or integrations, or retrieve analytics—use the separate [Form Plume API skill](https://formplume.com/skills/form-plume-api/SKILL.md). That skill uses the authenticated `/v1` management API and treats its organization API key as a server-side secret.

Some tasks need both skills: use this skill for the website form and the API skill for separate server-side automation. Never replace a public submission endpoint with a management API request from browser code.

## Before coding

1. Inspect the project, framework, existing form components, validation patterns, and visual language.
2. Ask for the Form Plume endpoint if the user did not provide it. Never invent or silently leave a placeholder public slug.
3. If the user has no endpoint, tell them to [create an account](https://formplume.com/signup), click **New form**, open its **Setup** tab, and copy the endpoint.
4. Read the [Quickstart](https://formplume.com/docs/quickstart.md) before implementing an unfamiliar integration.

A public endpoint has this shape:

```txt
https://api.formplume.com/f/{public_slug}
```

The public slug is safe to include in browser HTML. An access key for a private form is not. Never put an access key in client-side code, logs, screenshots, or source control.

## Choose the simplest submission method

Prefer a native HTML form when the user does not need an inline success state:

```html
<form action="FORM_PLUME_ENDPOINT" method="POST">
  <!-- labeled controls with name attributes -->
  <button type="submit">Send</button>
</form>
```

Use JavaScript only when the product needs inline loading, success, or error behavior. Send `FormData`, request JSON, and always check `response.ok`:

```js
const response = await fetch(endpoint, {
  method: "POST",
  headers: { Accept: "application/json" },
  body: new FormData(form),
});

if (!response.ok) {
  throw new Error("The form could not be submitted.");
}
```

Do not add an SDK. Form Plume does not require one. Preserve an existing server action or route only when the user needs server-only logic or a private form.

## Build an accessible, useful form

- Give every control a visible `<label>` connected with `for` and `id`. Do not use placeholders as labels.
- Give every submitted control a stable `name`. Use the correct `type`, `autocomplete`, `inputmode`, and `required` attributes.
- Keep instructions and errors close to their fields. Connect them with `aria-describedby` when appropriate.
- Preserve native keyboard behavior, visible focus, sufficient contrast, and comfortable touch targets.
- Use `<button type="submit">`. While submitting, prevent duplicate submissions and expose the busy state without removing the button label.
- Put validation errors in clear language, focus the first invalid field, and keep the user's entered values.
- Announce asynchronous success with `role="status"` and failures with `role="alert"`. Move focus only when it helps the user recover.
- Ask only for information the product needs. Do not log submitted personal information.
- Match the project's responsive layout, components, fonts, spacing, and dark mode.

## Configure Form Plume behavior

Code the interface, then tell the user which dashboard settings still need attention.

- Use ordinary named controls for submitted values. Check [Fields](https://formplume.com/docs/forms/fields.md) and [Special fields](https://formplume.com/docs/forms/special-fields.md) before using reserved names beginning with `_`.
- For native file uploads, add `enctype="multipart/form-data"`. For custom upload flows, follow [File uploads](https://formplume.com/docs/forms/file-uploads.md).
- Native HTML submissions redirect. JavaScript submissions stay on the current page unless the code redirects. Follow [Success and errors](https://formplume.com/docs/forms/success-and-errors.md).
- Configure recipients in [Email notifications](https://formplume.com/docs/notifications/email.md). Use [Reply-To](https://formplume.com/docs/notifications/reply-to.md), [Email routing](https://formplume.com/docs/notifications/routing.md), and [Autoresponders](https://formplume.com/docs/notifications/autoresponders.md) only when the form needs them.
- Start with Form Plume's built-in [Spam protection](https://formplume.com/docs/spam-protection.md). Add a [Honeypot](https://formplume.com/docs/spam-protection/honeypot.md), [Time trap](https://formplume.com/docs/spam-protection/time-trap.md), or [CAPTCHA](https://formplume.com/docs/spam-protection/captcha.md) according to those guides. Do not invent verification fields or tokens.
- Use [Domain restrictions](https://formplume.com/docs/forms/domain-restrictions.md) for public browser forms. Use [Private forms](https://formplume.com/docs/forms/private-forms.md) only from trusted server code.
- UTM values must be submitted as named fields. Follow [Submission metadata](https://formplume.com/docs/submissions/metadata.md).
- For downstream delivery, start with [Integrations](https://formplume.com/docs/integrations.md) or use signed [Webhooks](https://formplume.com/docs/integrations/webhooks.md).

Do not claim undocumented SDKs, management APIs, dashboard options, response fields, or customization. Open the relevant linked guide when behavior matters.

## Verify the result

1. Confirm that the real endpoint replaced every placeholder.
2. Submit valid data and confirm the submission appears in the Form Plume dashboard.
3. Test required fields, invalid email, server failure, repeated clicks, and keyboard-only use.
4. Test success and error behavior. Test a real file when the form accepts uploads.
5. Check mobile layout, focus styles, screen-reader announcements, the browser console, and the network response.
6. Report what was changed and list any remaining dashboard steps, such as recipients, redirects, CAPTCHA keys, or integrations.