# Why Form Plume?

See why a managed form backend handles storage, spam filtering, notifications, file uploads, and integrations so you don't rebuild it for every form.

You know how to build an API endpoint. You've sent emails from code. You've integrated with third-party apps. **So why use Form Plume?**

Because receiving a `POST` request is the easy part. The work starts after the first submission arrives.

Then comes dealing with email sender quirks, building third-party integrations, creating OAuth apps, filtering spam, handling retries, and keeping everything running.

## The endpoint is only the beginning

You still need somewhere to:

- Validate and store every submission
- Filter [bots, spam](/docs/spam-protection), and [disposable email addresses](/docs/spam-protection/email-hygiene)
- Send notifications to the right people
- Retry emails and webhooks when another service is down
- Handle [file uploads](/docs/forms/file-uploads) safely
- [Export data](/docs/submissions/export) when someone asks for a spreadsheet
- Let your team read submissions without accessing the database

None of these problems is difficult on its own. **Together, they become another
service you need to build, secure, monitor, and maintain.**

All for a contact form.

## What Form Plume does

Form Plume gives every form a public endpoint:

```html
<form action="https://api.formplume.com/f/{public_slug}" method="POST">
```

Point your form at it and we take care of what happens next:

- Submissions are stored in your dashboard
- Your team receives [email notifications](/docs/notifications/email)
- Spam is filtered without deleting legitimate submissions
- Files stay attached to the right submission
- [Webhooks](/docs/integrations/webhooks) and [integrations](/docs/integrations) receive the same data
- [Failed deliveries are retried](/docs/notifications/delivery)

You can start with the endpoint and enable the rest only when you need it.

## You still own the form

Form Plume does not generate your interface.

You keep control of:

- The HTML and components
- The fields you collect
- The design and validation
- The success and error experience
- The codebase where the form lives

We handle the backend behind it.

That means your form can look and behave exactly like the rest of your
product, without your product becoming responsible for form operations.

## It also saves future work

A simple form rarely stays simple.

Someone will eventually ask:

- Can this notify another email address?
- Can [sales and support receive different submissions](/docs/notifications/routing)?
- Can we block this spammer?
- Can users attach a file?
- Can we send this to [Slack](/docs/integrations/slack) or [our CRM](/docs/integrations)?
- Can I [download last month's submissions](/docs/submissions/export)?
- [Did that submission actually arrive](/docs/notifications/delivery)?

With your own endpoint, each request becomes another change to build and
deploy. With Form Plume, most of them are settings.

## When should you build it yourself?

Build your own backend when the form is part of your product's core logic.

Account creation, checkout, and workflows that must update your own data in a
single transaction should stay inside your application.

Use Form Plume when the form matters, but building and operating a form backend
does not make your product better.