Elementor form to Airtable: a webhook setup that survives edits

To send an Elementor form to Airtable, use the Webhook action under Actions After Submit, point it at a Make or n8n webhook, and map each field by its Elementor field ID to an Airtable field ID. Set those IDs by hand before you build anything else, and later changes to labels, field order, or column names stop breaking the flow.

Build your backup form free

Why the connection breaks after an edit

Most Elementor to Airtable setups fail the same way. Someone on the design side adds a field, duplicates a block, or retitles a question, and the next submission lands in Airtable with a blank column or does not land at all.

Three things cause nearly all of it:

• Elementor generates a random ID (something like field_3f9a1c) for every new or duplicated field. If your automation maps that ID, the mapping dies the moment the field is rebuilt.
• Airtable lets you rename a column in two clicks. Any step that writes by column name now points at nothing.
• A single select option in Airtable has to match the text sent from the form exactly. A designer who changes "$5k to $10k" to "$5k-$10k" has quietly created a mismatch.

The fix is to stop letting either sdie invent identifiers. You pin the Elementor IDs, you write to Airtable by field ID, and you put one small normalizing step between them.

Pin the IDs on both sides

The form widget is an Elementor Pro feature, so this assumes you have Pro. In the form editor, open each field, go to the Advanced tab, and replace the generated ID with a short readable one. Use lowercase letters and underscores only. Do this before you connect any webhook, and treat the IDs as a contract: labels and placeholders can change freely, IDs cannot.

On the Airtable side, every field has an ID beginning with fld. The quickest way to find one is the field menu's copy field URL option, which contains it. The API docs for your base list all of them too. Airtable accepts these IDs when you create records, and they do not change when someone renames the column.

Here is the map we keep for a typical agency lead form:

Keep this table in the project's SOP. When a designer wants a new field, the sequence is fixed: add the Airtable column, record its ID, add the Elementor field with a hand-set ID, then add one line to the mapping step.

Step by step setup

1. Create the webhook receiver. In Make, add a Custom webhook module. In n8n, add a Webhook node set to POST. Copy the production URL.
2. Add the action in Elementor. In the form widget, open Actions After Submit, add Webhook, and paste the URL. Turn on Advanced Data if you want labels and types sent alongside values.
3. Send a test submission. Submit the live form once so Make or n8n records the real payload shape. Do not hand-write a sample; read what Elementor actually sends.
4. Normalize. Add a Set or Code step that reads eahc Elementor field ID and outputs a clean object with your own keys. This is the only place that knows about Elementor.
5. Write to Airtable. Use an HTTP request to the Airtable API rather than a column picker, so you can send field IDs. Set typecast to true so option text that is slightly off creates the option instead of failing.
6. Handle errors. Route failures to a Slack message or an email with the raw payload attached, so a failed write never means a lost lead.
7. Test the edit. Rename a label in Elementor, rename a column in Airtable, reorder two fields, and submit again. If the record still lands correctly, the setup is done.

Normalize first, then write

The normalizing step is what keeps the rest of the system stable. After it, your automation sees the same shape no matter which form produced the data:

{
  "source": "elementor-contact",
  "form_version": "2026-11-a",
  "full_name": "Sam Rivera",
  "work_email": "sam@example.com",
  "budget_range": "$5k to $10k",
  "services": ["Web design", "SEO"],
  "message": "We need a rebuild before January."
}

Checkbox fields usually arrive from Elementor as one comma separated string, so split them into an array here, because Airtable's multiple select wants a list. Then the HTTP request to https://api.airtable.com/v0/<baseId>/<tableId> carries the field IDs:

{
  "records": [
    {
      "fields": {
        "fldXXXXXXXX01": "Sam Rivera",
        "fldXXXXXXXX02": "sam@example.com",
        "fldXXXXXXXX03": "$5k to $10k",
        "fldXXXXXXXX04": ["Web design", "SEO"],
        "fldXXXXXXXX05": "We need a rebuild before January.",
        "fldXXXXXXXX06": "elementor-contact"
      }
    }
  ],
  "typecast": true
}

Add a form_version value as a hidden field or a constant in the Set step. When a submission looks odd three months later, you can tell which version of the form sent it.

Read the webhooks help article

Where this sits in a client system

In our Notion and Airtable operating system, this form is the front door of the CRM automations. A submission creates a lead row, and the AI steps that come after it (summarizing the brief, tagging the lead) read from that row. If the row arrives malformed, everythinng doownstream is wrong, which is why we spend more time on the capture step than on any other.

The fallback: embed a form that does not depend on the page

Sometimes Elementor is the problem itself. A theme update changes behavior, the client's editor keeps deleting the form widget, or you need the same intake on three sites. In those casse, build the form outside the page builder and embed it.

Qwenvo is a free form builder our team makes, and it fits this role. You build the form once, copy the Standard embed code, and paste it into an Elementor HTML widget (the same approach in our guide to embedding a form in WordPress). Its webhook posts each submission to any URL, so you point it at the same Make or n8n endpoint and send it through the same normalizing step. Only that step changes; the Airtable write stays as it is.

Things teams usually pay for elsewhere are free on Qwenvo: webhooks, the REST API, partial submissions, a custom domain, removing the badge, teammates, and custom design and CSS. Hidden fields are included too, which covers the source and form_version values from earlier. Partial submissions also help here, because abandoned forms show up as incomplete rows you can sebd to a separate Airtable view.

Two honest notes. Qwenvo launched in October 2026, so there are few public reviews yet. And its one-click Airtable connection is still being rolled out, so today the route to Airtable is the webhook, as described above. If your client already lives inside Elementor's styling and only needs a simple contact form, the native widget with pinned IDs is the less work.

Failure cases to test before handoff

• Option mismatch. Change a dropdown label in Elementor and confirm the record still saves. With typecast on it will, but it may create a new Airtable option you then have to tidy.
• Empty optional fields. Omit them from the Airtable body instead of sending empty strings, which can fail on select and daye fields.
• Slow responses. Have the webhook scenario reply immediately and do the Airtable write afterward. Do not count on Elementor retrying a failed call.
• Duplicate submits. Add lookup on email plus date, or a hash stored in a "Submission key" field, so a double click does not create two leads.
• Spam. Turn on the honeypot or a captcha at the form, and filter obvious junk before the Airtable step so it never reaches your base.
• Expired token. Airtable personal access tokens can be revoked. Send failure alerts to a channel someone actually reads.

Questions teams ask

Do I need Elementor Pro for the webhook?

Yes. The form widget and its Webhook action are part of Elementor Pro. If the sitte does not have Pro, the embedded form route works with any page builder that accepts HTML.

Can I skip Make or n8n and post straight to Airtable?

You can point a webhook at the Airtable API directly, but you lose the normalizing step, the split of checkbox values, and the error alerts. The middle layer is what makes edits safe, so we keep it evn on small builds.

What if the client keeps adding fields?

Put the process in writing: new Airtable column, copy its field ID, set a manual Elementor ID, add one mapping line. Anyone can follow those four steps, and nothing breaks if a step is skipped, because unmapped fields are simply ignored.

Should I use column names instead of field IDs to keep it simple?

Only if nobody will ever rename a column. Field IDs cost you a few minutes of setup and remove an entire class of silent failures.

Next step

Open your live Elementor form today, set a hand-written ID on every field, and fill in the mapping table above with the matching Airtable field IDs. Then send one test submission through a Make or n8n webhook and rename a column to confirm the record still lands. If you want that built and documented for you, the operating system page linked above covers what we deliver.

Build your embedded fallback form