Webflow Salesforce integration: connecting Webflow forms to Salesforce or HubSpot without losing leads.

A Webflow Salesforce integration runs through Web-to-Lead, a third-party app, middleware, or a custom API build, because Webflow's own Salesforce page says Salesforce has no official Webflow app. Webflow does maintain a HubSpot app. Each route has documented limits that can drop leads, so this guide compares them and gives a test plan for B2B SaaS marketing leads, as of October 19, 2026.

What routes exist for a Webflow Salesforce integration?

A Webflow Salesforce integration is any setup that carries a form submission from Webflow to Salesforce as a lead or contact. Webflow's own Salesforce page says Salesforce doesn't offer an official Webflow app, so even two powerful platforms need a connection you assemble yourself. It describes three ways to do that: a third-party app (it lists Form Connector, Pipedream, and Salespeak), Web-to-Lead, and a custom build that uses OAuth 2.0 to call the Salesforce API from serverless code such as AWS Lambda or Netlify Functions. It also mentions Zapier as the simpler option. HubSpot is easier on one point: Webflow maintains its own HubSpot app, so a form made of text inputs can reach HubSpot without middleware.

The table puts the routes side by side. Every limit in it comes from the vendor's own documentation, read on October 19, 2026.

One route no longer exists. Webflow's help center says it sunset Webflow Logic as of June 27, 2025, disabled existing flows, and turned forms that were connected to flows into standard Webflow forms. If an older Webflow site sent leads to a CRM through Logic, those leads now stop at Webflow, so check old forms for flows that went quiet.

Webflow Optimize also has a Salesforce integration, but it is not a way to capture leads. Webflow's help article, updated March 13, 2026, limits it to the Enterprise plan and says it reads Salesforce data from the Account, Opportunity, Contact, and Lead tables, up to 20 fields per table, for targeting and reporting. The article doesn't describe form submissions.

How do you connect Salesforce to Webflow with Web-to-Lead and HTML code?

Web-to-Lead is Salesforce's built-in way to receive a web form and the shortest path from Webflow to Salesforce: you generate a form in Setup, and the HTML code it produces posts each submission into Salesforce as a new lead. Webflow's Salesforce page describes two ways to use it on a Webflow website: paste the generated markup into an Embed element, or take a native Webflow form and point its action at webto.salesforce.com, with a hidden field that holds your Salesforce organization ID. The page also says styling is limited with Web-to-Lead, which is the price of the simplest route.

On the Salesforce side the steps are short:

1. In Setup, open Web-to-Lead and confirm it is enabled. Salesforce lists this as the first check when a form creates no leads.
2. Choose a Default Lead Creator with Modify All Data, Send Email, and Access Activities, granted through a permission set or a profile, not a mix of both. This user also receives Salesforce's error emails.
3. Select Create Web-to-Lead Form, move the Salesforce fields you need to Selected Fields, include every field the Lead object requires, set a Return URL for the thank-you page, and decide on reCAPTCHA. Salesforce offers a Require reCAPTCHA Verification option to cut spam, and its troubleshooting article says to remove reCAPTCHA and other customization while you debug.
4. Click Generate, save the markup as an .html file, and test that Salesforce form on its own before you touch Webflow. Salesforce's advice is that if the default form works, the problem is probably in your changes.
5. Add the markup to Webflow in an Embed element, or rebuild the fields in a native form and set its action. Add Lead Source as a hidden field with a fixed value, one per form.
6. Before launch, uncomment the debug and debugEmail hidden inputs in the generated HTML and add your address. Salesforce then emails debugging information with each test submission. Remove them again before the page goes live.

The limits matter more than the setup. Salesforce says Web-to-Lead creates up to 500 leads in a 24-hour period on Professional, Enterprise, Unlimited, Performance, and Developer editions. Extra requests wait in a queue that holds 50,000 combined Web-to-Lead and Web-to-Case requests. When the queue is full, new requests are rejected and not stored, administrators get an email about the first five rejections, and Salesforce says the requests cannot be recovered. The limit resets at midnight UTC, and Salesforce support cannot clear the queue for you; it can only raise the daily limit temporarily. Salesforce's own pages describe the overflow a little differently: the Leads FAQ says the Default Lead Creator receives an email with the additional lead information, while the 2026 queue article says requests are lost for good. Plan for the stricter version.

For most B2B sites, 500 a day is far above real form volume, so the exposure is spam. Salesforce's permanent fix is validation or a captcha on the web side.

On the Webflow side, setting a custom action URL on a form sends the submission straight to that address. Webflow's help center says this bypasses Webflow's form processing, so Webflow stops sending notification emails. It doesn't say whether the submission is still stored in Webflow, so don't count on a backup copy until you have tested what your site keeps.

How do you connect Webflow to HubSpot, and when do you need custom code?

Webflow's HubSpot app connects native Webflow forms to HubSpot, so the form keeps its design in Webflow and the submission goes to HubSpot. Webflow now documents a current HubSpot app and a legacy one. The rules below come from the current app's help article, updated November 7, 2025, and Webflow's April 21, 2026 blog post on linking forms. You need custom code in two situations: the HubSpot tracking code, which Webflow's blog says needs custom code access, and a form the app can't map, which you send yourself through HubSpot's Forms API.

Installing the app takes Site Admin or Designer permissions and a HubSpot account with access to the target forms. In the app you add a Webflow form, name it, and pick the fields. The connection uses HubSpot's non-HubSpot forms script, and mapping works when each field's name attribute matches HubSpot's field name. Webflow's blog is stricter: names are case-sensitive and must match the HubSpot internal property name exactly, which you find under Settings, Data Management, Properties, and the form needs an email field because HubSpot won't create a contact without one. On the plan side, the blog says Starter plans don't support custom code injection, while paid Workspace plans (Core, Growth, Agency, Freelancer) and paid Site plans (CMS, Business, Ecommerce) qualify.

The limit most teams hit is field types. The help article says the app supports text input fields only. In Webflow forms, dropdown menu fields, radio buttons, checkboxes, and text areas are not supported, so a B2B form with a company-size dropdown or a consent checkbox needs another approach. Webflow's blog points to the iframe or the developer embed for those field types. An iframe is managed entirely in HubSpot. A developer embed renders an HTML template of the form inside Webflow so you can style it like any other element, but it requires HubSpot Marketing Professional or Enterprise, and the form reverts to an iframe if the app detects changes made outside the Style panel.

HubSpot's own article on non-HubSpot forms sets the boundaries for any form HubSpot reads this way. It collects submissions from static HTML forms once the tracking code is installed, and the form needs form tags, an email-type input, and a standard submit input. It does not capture iframe forms, forms with JavaScript bound to the submit event or a button click, forms added after the page loads, single-page-app forms, sensitive fields, or hidden fields. Only single-line text properties receive mapped data, and submissions that share a cookie go to one contact even when the emails differ. The article doesn't mention Webflow, so read these as limits to test for, not as predictions about your form.

When the app can't carry a form, a Webflow webhook can call your own serverless function, which posts to HubSpot's Forms API. A webhook is a message Webflow sends to your server when an event happens, here a form submission. HubSpot's docs list this endpoint under legacy v3: a POST to api.hsforms.com/submissions/v3/integration/submit/{portalId}/{formGuid} with a JSON body. Only fields is required. Each field carries an object type ID (0-1 for contacts), a name, and a value. An optional context object takes the page URI, the page name, and the visitor's tracking cookie token as hutk, and a legalConsentOptions block records consent text or a legitimate interest basis. A minimal body, built from the documented fields as an illustration rather than HubSpot's own example, looks like this:

{
  "fields": [
    { "objectTypeId": "0-1", "name": "email", "value": "visitor@example.com" },
    { "objectTypeId": "0-1", "name": "company", "value": "Example Ltd" }
  ],
  "context": {
    "hutk": "<tracking cookie token>",
    "pageUri": "https://www.example.com/contact",
    "pageName": "Contact"
  }
}

HubSpot documents the ways a call can fail, including BLOCKED_EMAIL, FIELD_NOT_IN_FORM_DEFINITION, FORM_HAS_RECAPTCHA_ENABLED, and INVALID_HUTK, and it returns a 429 when a rate limit is exceeded, without giving numbers on that page. Log every response, not only the errors you expect.

This is custom development, and it carries the usual cost: someone owns the code, the retries, and the monitoring. Webflow's developer docs say a webhook that returns a non-200 response is retried up to three more times at 10-minute intervals and then deactivated, with an email notice, so the function should answer quickly and do its slow work afterwards. Used well, custom code extends a website's functionality past what any app maps, but it needs technical knowledge of both APIs for as long as the form exists.

How do you integrate Salesforce with middleware and marketing automation tools?

Middleware is the usual way to integrate Salesforce without code: a service that sits between Webflow and Salesforce or HubSpot. It starts a workflow on specific events, such as a new form submission in Webflow, and the workflow creates or updates a record in the CRM. Zapier's Salesforce and Webflow page lists an instant New Form Submission trigger and templates that add new leads in Salesforce, create Salesforce contacts, update leads or other records when a submission arrives, and add submissions to Salesforce campaigns as contacts, which Zapier marks as a premium template. It also warns that limits such as API call limits may apply. Zapier also lists a template that creates Webflow CMS collection items from new form submissions; that one suits content you plan to publish, not lead data.

The value is that you can automate workflows around the lead without writing code: look up an existing contact before creating one, set the owner by territory, and notify the sales team in a chat channel. Each step can automate sales processes that someone would otherwise run by hand, replacing one of the repetitive tasks, and each step is one more place to fail. Marketing automation platforms work the same way from the other side. HubSpot receives forms through the app described above, and Webflow's Salesforce page also mentions Pardot form handlers for teams that run marketing automation inside the Salesforce ecosystem.

Error handling is where the tools differ, and it decides whether a failed run is a delay or a lost lead. On Zapier, replaying an errored step is available on every plan, and on the Free plan manual replay works only for runs with an errored status. Replaying a whole run and autoreplay need Professional, Team, or Enterprise. Autoreplay tries up to five times per step, the last about 10 hours and 35 minutes after the first error, and Zapier says it sends no error notification emails until the final attempt fails. It also says Filter and Paths steps are never replayed, so a Zap that routes leads with Paths needs its own check. Replays must happen within 60 days of the trigger, and Zapier doesn't guarantee that a replay succeeds.

On Make, incomplete executions are disabled by default. You switch on Store incomplete executions in the scenario settings, and Make can then retry automatically for supported error types or let you resolve or delete the runs by hand. How many it keeps depends on your plan, and the help page doesn't say what happens to failed runs when the setting is off.

Whichever tool you use, add a step before the CRM step that appends every submission to a spreadsheet such as Google Sheets, or to any other store you control. If the CRM call fails, the raw submission still exists, and the monthly count described at the end of this post has something to compare against. The step adds almost nothing to the workflow and gives you a record that doesn't depend on the CRM. Other guides also name Coefficient as a no-code option and MuleSoft for API-led connectivity between Webflow and Salesforce. We did not test or verify either, so they are outside this comparison.

Which route should you choose to integrate Webflow and capture leads?

Choose by CRM, volume, and who will maintain the setup, and start by defining which data needs to sync. List the fields your sales team actually uses to qualify a lead, usually name, work email, company, one qualifying question, and source, and decide which Salesforce object each one lands on: the Lead object, Contact and Account, or a campaign member. Define which fields will sync data between the two platforms, and leave the rest out. Fewer data fields mean fewer places to break. A lead that arrives with an owner, a status, and a source lets marketing and sales efforts work from the same record and gives the sales processes in Salesforce something to act on. Routing every form into one CRM also centralizes website submissions in a single customer database, instead of leaving them in a handful of inboxes. The aim is instant access for the sales team, not a lead found in an inbox the next morning.

You also need three things in place before any route works: a Webflow account with a published site, a Salesforce account with a user who has the necessary permissions to create leads, and, for middleware, an account with the tool you picked. Check the Webflow plan too. The Starter site plan limits a Webflow site to 50 total form submissions, and Webflow's help center says the count doesn't reset and new submissions are no longer collected after that.

A rule of thumb, based on the limits above:

• Salesforce, one or two simple forms, low volume: Web-to-Lead with HTML code, because no extra vendor sits between the form and Salesforce.
• Salesforce, marketing owns the setup and there is no developer: a marketplace app, Zapier, or Make, which map fields and route leads without code.
• Salesforce, routing rules or volume near the daily cap: a custom build on the API, where you control retries, validation, and what is stored.
• HubSpot, a form of text inputs: the Webflow HubSpot app, which keeps the form design in Webflow.
• HubSpot, dropdowns, checkboxes, or consent text: the iframe, the developer embed, or the Forms API.

Match the route to your team's technical expertise. Web-to-Lead and the HubSpot app suit non-technical users who can paste code and match field names. Middleware needs someone who can read a run history and fix a failed step. A custom build needs a developer for as long as the form exists.

As your business grows, revisit the choice: a route that works at 20 leads a week can strain when a campaign sends thousands of visitors to the page. Watch the limits above: 500 leads a day for Web-to-Lead, the limits Zapier says may apply, and the five-attempt autoreplay window.

Where do form submissions get lost between Webflow and the CRM?

Form submissions get lost at the seams between two tools: a plan limit, a setting that skips a step, a vendor queue that fills, or an alert nobody reads. For professional websites that depend on lead capture, a silent failure costs a lead you paid to attract. The table lists the documented ones, each from the vendor's own page.

Most of these fail quietly. The Salesforce overflow, the Zapier delay, and the HubSpot hidden-field gap produce no error on the page the visitor sees, so the visitor gets the same thank-you message either way. That is why the test list in the next section checks the CRM record, not the confirmation.

Salesforce's troubleshooting article adds two more places to look when a form creates no leads: active lead assignment rules, which should assign each new lead correctly, and lead validation rules, which you can switch off temporarily to see whether one is blocking creation.

How do you test the integration process before launch?

Test every form on the published site, not in the Webflow Designer, by submitting a real entry and tracing it from Webflow to Salesforce or HubSpot through each stage: the Webflow submissions tab, the middleware run history or webhook log, and the Salesforce lead or HubSpot contact, with every field compared against what you typed. Webflow's HubSpot guidance agrees: publish first, because the app needs at least one submission to detect fields, and confirm on staging that submissions reach HubSpot before you publish to production.

Salesforce gives you two aids. The debug and debugEmail hidden inputs in the generated form make Salesforce email debugging information with each test, and the default form it generates is your control: if the default form creates a lead and yours doesn't, the problem is probably in your changes. For HubSpot, Webflow's blog says to view HTML code through the browser's page source on the published page and search for hs-script-loader to confirm the tracking code loaded in Head Code, and to check the contact's timeline for page view events.

Run the list again after every release that touches a form, a field name, or the integration settings. Webflow's older HubSpot forms integration article adds two reasons: each Form block needs a unique form name in the Webflow Designer, and duplicate form names can break mapping.

What data management rules keep customer data and attribution accurate?

Settle five rules before the first lead arrives: which fields are required, what happens to an existing record, where the source is stored, how consent is recorded, and which sensitive fields stay out. Writing them down is the data management work that keeps customer data consistent between Webflow and Salesforce or HubSpot, and it is cheaper than cleaning duplicates later. Fields captured at submission, such as company size, role, and source, are also what let marketing personalize campaigns and sales tailor the first reply.

Start with field mapping, because most silent errors begin there: a field name that differs by one letter, a picklist value Salesforce doesn't have, or a field the CRM doesn't define. HubSpot's Forms API names these failures outright, with errors such as FIELD_NOT_IN_FORM_DEFINITION, VALUE_NOT_IN_FIELD_DEFINITION, and REQUIRED_FIELD. Middleware tools hide the same problems in a run history unless someone reads it. Map fields once, in a sheet: the Webflow field name, the CRM field, the type, whether it is required, and the allowed values. Ensuring data consistency starts with that sheet, and data accuracy depends on keeping it current when a form changes.

Decide what a repeat submission does. A create record step makes a new record every time, and an update step changes an existing record. For a B2B form you usually want to find an existing contact or lead by email first and update it, and create a new record only when none exists. Zapier's templates cover both patterns, including one that updates Salesforce records when new submissions occur. The CRMs have their own rules too: HubSpot sends submissions that share a cookie to one contact, and Salesforce duplicate rules can block a Web-to-Lead insert.

Capture the source at submission time. Salesforce says it has no automated feature that tells you how a lead was created, so its guidance is to add the Lead Source field as a hidden field with a fixed value on each form, and to add a picklist value per page if you run several forms. UTM values need their own custom Lead fields: Salesforce's article on adding fields describes creating the field and then generating the form again. On HubSpot forms, hidden fields can capture URL parameters such as UTM values into contact properties, but HubSpot's non-HubSpot forms tool does not capture hidden fields, so a UTM stored in a hidden field on a Webflow form may never arrive. Test it. If it fails, send the values through the Forms API as fields, which must exist in the form's definition or the call fails with FIELD_NOT_IN_FORM_DEFINITION. Our guide to B2B marketing attribution without an attribution tool covers UTMs, self-reported source, and CRM fields in more detail.

Record consent where the law and your privacy policy require it. The Forms API accepts a legalConsentOptions block and documents an error type, MISSING_PROCESSING_CONSENT, for a submission that lacks it. For the cookie and tag side of consent on a Webflow site, see our post on consent mode v2 in Webflow.

Keep sensitive customer data out of lead forms. HubSpot's non-HubSpot forms tool doesn't capture sensitive fields, and a demo request rarely needs more than the fields on your list. Don't copy lead data into the Webflow CMS either: its collections hold website content for your pages, not customer records. Anything you send through middleware passes through another company's systems, so list every tool that sees the data and limit who can open those accounts. Use a dedicated integration user for each Salesforce connection, not a person's login, so a change to one account doesn't break lead capture.

One reporting trap remains. Salesforce's queue article says a record held in the pending queue shows the date Salesforce created it, not the date of the web submission, so a lead submitted yesterday and held for 24 hours shows today's date. If you report on lead response time, store the submission time in its own field.

What should you monitor after launch, and who owns it?

One named person owns the integration, and three checks keep it honest: a monthly count that compares Webflow submissions with CRM records, alerts that reach a person, and a retest after every release that touches a form. Treat the integration as part of business operations: a Webflow website that collects leads needs an owner and a calendar entry, not a build that ends at launch.

For the count, take one month of Webflow data, add the spam inbox, and compare the total with the leads or contacts created in the CRM for the same forms, and with the Google Sheets log if you kept one. A gap is a leak. Know where each copy lives: the data stored in Webflow, the log, and the CRM record. A custom form action and reCAPTCHA added through the HubSpot app both route around Webflow's standard form handling, and Webflow's blog says reCAPTCHA submissions won't appear in the form submissions tab, so for those forms count in the middleware log or the CRM instead.

For alerts, send every failure notice to a named person or a monitored shared channel. Webflow's notifications go to the account email by default and can be set per form, and its help center warns that role addresses such as admin@ or info@ may cause deliverability issues. Salesforce sends its lead-creation error emails to the Default Lead Creator, Zapier waits for the final autoreplay attempt before it emails, and Webflow emails a notice when it deactivates a webhook.

For the retest, rerun the test list on any form you changed, and after any rename of a field in Webflow, HubSpot, or Salesforce. Webflow's blog notes that reconnecting the HubSpot app alone won't restore existing mappings, so you delete and re-add the form integration on each connected site. Vendor limits change too, and the numbers in this post are dated October 19, 2026. Recheck the Salesforce limit, the Webflow plan limits, and the HubSpot field types before you rely on them for a launch.

We are a Webflow agency for B2B tech companies, and we connect CRM and marketing automation during our builds, so we have an interest in this topic. If you want a second pair of eyes on a setup, see our Webflow enterprise agency page.

Questions about Webflow Salesforce integration