Send Framer form submissions to SubmissionBuddy via webhook

Published 2026-07-15

Framer's native form component is a drag-and-drop block: open Insert > Forms, drop it on the canvas, style the fields. Unlike a plain HTML <form>, though, you don't get to set an action attribute pointing at a URL of your choosing — the form always submits to Framer's own backend first. What Framer does after that is configurable per form under Send To: email, Google Sheets, one of Framer's built-in integrations (Formspark, HubSpot, Typeform), or — the one that matters here — a webhook.

That's the honest integration path for a Framer site: not an Embed block with a raw <form> (that works too, but throws away Framer's native field styling and built-in spam protection), but connecting the native form's webhook destination directly to a SubmissionBuddy endpoint. Here's the exact setup.

Connect the webhook

1. Select your form on the canvas.

2. In the right sidebar, find Send To and click Add….

3. Choose Webhook.

4. Enter your endpoint URL — it must start with https://:

   https://api.submissionbuddy.io/f/your-form
   

5. Publish your site.

No code component, no custom JavaScript. Framer's native form still handles its own success/error UI states, its own field validation, and its own built-in rate limiting and spam protection — the webhook is purely where a copy of the validated submission gets sent.

What Framer actually sends, and what your endpoint must return

This matters more here than on most platforms, because Framer's webhook contract is stricter than a browser form post:

• Framer sends the submission as JSON, with input names as keys — SubmissionBuddy accepts application/json natively, so this just works.
• Your endpoint must return a 2xx status code. SubmissionBuddy's default success response is 202 Accepted, which satisfies this.
• Framer does not follow redirects. If a 3xx response comes back, Framer treats it as a failure and retries. This means you should not add a _redirect field to a Framer-connected form — Framer's own form already shows its own success state to the visitor, and a 303 from SubmissionBuddy would just cause Framer to log a retry against a request that actually succeeded.
• If your endpoint doesn't return 2xx, Framer retries the webhook up to 5 times automatically — on top of SubmissionBuddy's own queue-level retries once the request lands.

Spam protection: the honeypot field

Framer forms ship with their own built-in spam protection and rate limiting on the native form itself, which is a first layer. You can add SubmissionBuddy's honeypot as a second layer:

1. Add a text input field to your form.
2. Name it _honeypot.
3. Set its opacity to 0 or move it off-canvas so real visitors never see it (Framer's layer properties handle this without custom code).

A bot that fills in every visible field will trip it — SubmissionBuddy silently drops the submission (no storage, no notification) while still returning a normal-looking success, so the bot never learns it failed. The _honeypot field itself is stripped before the submission is stored, so it never appears in your dashboard.

Signing the webhook (optional, but available)

Framer supports signing webhook requests: set a secret of at least 32 characters on the webhook destination, and every request from Framer includes a Framer-Signature header (an HMAC-SHA256 hash of the body and submission ID) plus a Framer-Webhook-Submission-Id header. SubmissionBuddy's ingestion endpoint doesn't currently verify this signature — the honeypot field and SubmissionBuddy's own per-IP/per-form rate limiting are what stand between your form and abuse. If you need strict webhook-origin verification, that's a gap worth knowing about going in.

What happens to the submission after Framer relays it

Once SubmissionBuddy receives the webhook POST, the submission is written to durable storage before the 202 goes back to Framer — nothing sits in memory waiting to be processed. From there it flows through independent, retryable stages: a database write (making it searchable and exportable in your dashboard) and an email notification to your team. There's no schema to configure on either side — whatever field names your Framer form uses show up as-is in the dashboard, and you can add or rename fields anytime without touching SubmissionBuddy.

The free tier

Sign up free — 100 submissions/month across up to 2 forms, no credit card. That's on top of whatever Framer plan you're already paying for hosting; the two limits are unrelated.

Framer's webhook documentation checked 2026-07-15. Code samples verified against the live SubmissionBuddy API the same day.