Salesforce Website Integration: Connect WordPress, Webflow and Your Forms

In this article
- Salesforce’s free, built-in Web-to-Lead works on any website, including WordPress and Webflow. It is a good start for simple contact forms, but it creates leads only, caps out at 500 leads a day by default and gives you little error handling.
- On WordPress, a form plugin’s Salesforce add-on (Gravity Forms, Ninja Forms, WPForms) uses the Salesforce API: it can update existing records, write to contacts or custom objects and avoid duplicates. Your Salesforce edition needs API access.
- Webflow has no native Salesforce sync since Webflow Logic was retired: use the Web-to-Lead HTML, a form submission webhook into Zapier or Make, or a small serverless function. Unbounce, Typeform and Formstack have their own connectors; Cognito Forms goes through Zapier, Make or Power Automate.
- Whatever the tool, the hard part is the same: capture UTMs in hidden fields, block spam before it reaches Salesforce, handle duplicates, store consent, and test every path in a sandbox.
Jump to
- Your options for connecting a website to Salesforce
- How website data reaches Salesforce
- Web-to-Lead: the free built-in option
- WordPress Salesforce integration
- Webflow Salesforce integration
- Unbounce, Typeform, Formstack and Cognito Forms
- Account Engagement forms and form handlers
- Custom API integration: when a small function beats a plugin
- Field mapping: what goes where
- Capture UTMs and attribution properly
- Common pitfalls and how to fix them
- Spam, consent and privacy
- When custom integration makes sense, and what it costs
- Go-live checklist
- Where Gilzor fits
Your options for connecting a website to Salesforce
There are six common ways to get form data from a website into Salesforce. They differ in what they can create, how they handle errors and duplicates, and whether your Salesforce edition needs API access. For the wider picture of Salesforce integrations, see our Salesforce integration guide.
| Option | What it creates | Works with | Cost level | Effort | Main limits |
|---|---|---|---|---|---|
| Web-to-Lead (built into Salesforce) | Leads, optionally as campaign members | Any site that can hold an HTML form | Included with Salesforce | Hours | Leads only, 500 a day by default, no update of existing records, little error feedback |
| Form plugin add-on (Gravity Forms, Ninja Forms, WPForms) | Leads, contacts, accounts, other objects; can update existing records | WordPress | Plugin license, often the top tier | A day or two per form | Needs Salesforce API access; one more plugin to keep updated |
| Form or landing page tool connector (Unbounce, Typeform, Formstack) | Leads and, depending on the tool, other objects | The tool’s own forms and pages | Usually on mid or higher plans | Hours | Mapping and logic limited to what the vendor built |
| Zapier, Make and similar | Whatever a trigger and action can carry | Webflow, Cognito Forms, almost any form tool | Paid plan; tens to hundreds of dollars a month with volume | Hours per flow | Duplicates, retries and monitoring are your job |
| Account Engagement (Pardot) forms and form handlers | Prospects that sync to leads or contacts | Any site, if you already run Account Engagement | Part of an Account Engagement license | Days | Tied to Account Engagement; form handlers have their own quirks |
| Custom API integration (serverless function or backend) | Anything, with your own matching, routing and logging | Any site or app | Build cost plus upkeep | One to a few weeks | You own the code, credentials and monitoring |
Not sure which fits? Four questions:
Which Salesforce website integration fits you?
How website data reaches Salesforce
Every option follows the same path. A visitor submits a form, something checks it and carries it to Salesforce, and Salesforce rules decide what happens to the record. Most problems come from the middle step doing less than people assume.
Web-to-Lead: the free built-in option
Web-to-Lead is a Salesforce feature that generates an HTML form. When a visitor submits it, the browser posts the data straight to Salesforce, which creates a lead. According to Salesforce Help (as of October 2026), it is available in Essentials, Group, Professional, Enterprise, Performance, Unlimited and Developer editions. Because the form posts from the visitor’s browser rather than through the API, it works without API access. That makes it the only no-cost route for editions without the API.
What you should know before you rely on it:
- The daily cap. Salesforce Help puts the Web-to-Lead limit at 500 requests in 24 hours. Extra submissions go into a pending queue shared with Web-to-Case, which holds up to 50,000 requests and submits them when the limit refreshes; once that queue is full, new submissions are rejected. The Default Lead Creator gets an email saying the daily limit was exceeded. You can request a higher limit from Salesforce Support.
- Spam counts. Bot submissions use up the same daily limit as real leads. According to Salesforce Help, reCAPTCHA verification is on by default; to show the widget you select “Include reCAPTCHA in HTML” and choose a reCAPTCHA API key pair when you generate the form.
- Leads only. Web-to-Lead creates a new lead every time. It doesn’t look up an existing contact or update a record, so returning visitors become new leads unless your duplicate rules or a lead matching tool step in.
- Thin error feedback. The browser posts straight to Salesforce, so your site never learns whether a lead was created. Salesforce runs validation rules first and creates no lead if a value fails or a required field is empty. For testing, the generated HTML includes commented-out debug fields that email you details after each submission.
- The default lead creator needs Modify All Data, Send Email and Access Activities, granted through one permission set or one profile. Use a dedicated user rather than a person who might leave.
How to set up Web-to-Lead, step by step
- Create the fields firstAdd custom lead fields for anything the form collects beyond the standard ones: UTM source, medium, campaign, content, term, landing page, click ID, consent. Web-to-Lead can only fill fields that exist.
- Set lead settings and assignmentIn Setup, open Lead Settings and choose the default lead owner. Then build an active lead assignment rule with a rule entry for web leads, so new leads go to the right rep or queue instead of piling up with the default owner.
- Configure Web-to-LeadIn Setup, open Web-to-Lead and click Edit. Keep Require reCAPTCHA Verification on, choose the default lead creator and, if you want an automatic reply, a default response template (marked Available for Use). Save. You need the Customize Application permission for this.
- Generate the formClick Create Web-to-Lead Form, pick the fields (add Campaign if you want leads added as campaign members) and enter the thank-you page URL. To add the reCAPTCHA widget, select Include reCAPTCHA in HTML and choose the reCAPTCHA API key pair; with verification required, the form on your site must include that reCAPTCHA code. Click Generate and copy the HTML.
- Put it on the siteOn WordPress, paste it into a Custom HTML block; on Webflow, into a Code Embed element. Restyle it freely, but don’t rename the field
nameattributes or remove the hiddenoidfield. - Add hidden fields and the UTM scriptAdd hidden inputs for your UTM and page fields, using the field IDs from the generated HTML, and a short script that fills them from the URL (see the attribution section below).
- Test in a sandbox, then in productionGenerate the form in a sandbox first, uncomment the debug fields, submit real-looking test leads and check owner, campaign, UTMs and the auto-response. Repeat in production with a test email you can delete afterwards.
A validation rule that demands a field your form doesn’t collect, or a duplicate rule set to block, can stop a web lead from being created. Test both in the sandbox with a submission that matches an existing record, and decide what should happen: create, flag or merge.
WordPress Salesforce integration
On WordPress, the usual route is the Salesforce add-on of the form plugin you already use. These add-ons call the Salesforce API, so they can do what Web-to-Lead can’t: update existing records, write to contacts, accounts or custom objects, and use conditional logic. All of them need a Salesforce edition with API access.
- Gravity Forms Salesforce integration. Gravity Forms has an official Salesforce add-on, built and maintained by Gravity Forms. According to its add-on page (as of October 2026), it comes with the Elite and Nonprofit licenses, supports leads, contacts, accounts and other objects through multiple feeds per form, can update existing records instead of creating duplicates and sends data only when conditions you set are met. Gravity Forms also offers a connection verification tool to check your Salesforce account’s API access. Don’t confuse it with older third-party add-ons that use similar names.
- Ninja Forms Salesforce integration. Ninja Forms sells a Salesforce CRM add-on, included with its Pro membership according to its listing. It can send data to leads, contacts, accounts, opportunities and custom objects, link submissions to a campaign, and pass file upload links. When it finds a duplicate, it flags it and creates a Salesforce task for review.
- WPForms. The WPForms Salesforce addon lists accounts, campaigns, cases, contacts, leads, opportunities and products among the objects it can work with. According to WPForms’ pricing page (as of October 2026), it is part of the Elite plan.
- Contact Form 7, Elementor forms and others. Without an official Salesforce add-on, post the form to Web-to-Lead, use a Zapier or Make integration, or send it to a small custom endpoint. Be careful with free third-party connector plugins: you hand them Salesforce credentials.
Whichever add-on you use, connect it with a dedicated integration user, not an admin’s personal login. According to Salesforce Help, supported editions include a limited number of free Salesforce Integration user licenses, which exist for exactly this API-only purpose. If you are planning or rebuilding the site itself, our guide to WordPress website development cost covers the budget side.
Webflow Salesforce integration
Webflow has no built-in Salesforce sync. Webflow retired its Logic automation tool on June 27, 2025 and named Zapier and Make as its recommended partners for automations. That leaves three practical routes:
- Embed Web-to-Lead. Paste Salesforce’s generated form into a Code Embed element. Free and quick, with every Web-to-Lead limit above. Styling it to match your Webflow forms takes some CSS.
- Webhook into Zapier or Make. Keep native Webflow forms and send submissions to Salesforce through a flow: a Webflow form submission trigger, a search for an existing lead or contact by email, then create or update. Salesforce is a Premium app on Zapier, so it needs a paid Zapier plan.
- Webhook into a serverless function. Webflow can send a
form_submissionwebhook to your own endpoint. According to Webflow’s developer docs, webhooks created through the API carry signature headers you can verify; webhooks added in site settings don’t. Your endpoint must return HTTP 200: failures are retried up to three more times at 10-minute intervals, and if failures continue, Webflow deactivates the webhook and emails you. Log every payload so nothing is lost while it is down.
The serverless route is a small amount of code (often a few hundred lines on Cloudflare Workers, AWS Lambda or similar) and gives you matching, routing and logs under your control. If you are redesigning the site anyway, plan this form plumbing together with the web design work, not after launch.
Unbounce, Typeform, Formstack and Cognito Forms
Landing page and form tools each handle Salesforce differently. Check what your plan includes before you design the flow around it.
| Tool | How it connects to Salesforce | What to check |
|---|---|---|
| Unbounce | Native integration that sends landing page form submissions to Salesforce as leads | Which Unbounce plan includes it; how checkbox values and hidden UTM fields map |
| Typeform | Typeform’s own Salesforce app maps responses to standard or custom objects such as leads, contacts and cases | Needs one of Typeform’s Growth plans (its help center and pricing page name different tiers, so confirm with Typeform); required Salesforce fields must always get a value |
| Formstack | Two products: Formstack Forms pushes submissions to Salesforce through the API, while Forms for Salesforce is a native app where forms are built and data stored inside your Salesforce org | Whether you want data kept only in Salesforce (native app) or in Formstack too |
| Cognito Forms | No native connector; Cognito Forms points to Zapier, Make or Microsoft Power Automate | Cognito lists Pro, Team or Enterprise plans for this; plus the automation tool’s own plan |
| HubSpot forms | Through the HubSpot Salesforce connector, if HubSpot runs your marketing | See our HubSpot Salesforce integration guide |
Plan names and inclusions change often. Treat the table as a starting point as of October 2026 and confirm on each vendor’s pricing page.
Account Engagement forms and form handlers
If you run Marketing Cloud Account Engagement (formerly Pardot), website data usually goes there first. Prospects then sync to Salesforce leads or contacts through the Salesforce connector, with scoring, completion actions and tracking on top. You have two choices:
- Account Engagement forms are built and hosted in Account Engagement and embedded on your site. They handle tracking, progressive profiling and error messages for you, but styling is limited.
- Form handlers let you keep your own forms (a WordPress plugin, a Webflow form, a custom form) and post a copy of the data to Account Engagement.
According to Salesforce’s troubleshooting article for form handlers, they don’t accept the multipart/form-data encoding, so forms with file uploads need another route. External field names are case-sensitive and must match the form’s field names exactly. Account Engagement keeps no log of failed form handler submissions, so keep your own copy. Kiosk mode and server-side posts stop the visitor cookie from being set, which breaks later activity tracking for that prospect. If you are choosing between marketing automation platforms, our Marketo Salesforce integration guide covers the main alternative.
Custom API integration: when a small function beats a plugin
A custom integration here is rarely a big system. Usually it is one endpoint that receives form submissions from the site and talks to Salesforce. It makes sense when:
- several sites, forms or brands feed one Salesforce org and need one set of rules;
- you need to look up existing contacts and accounts and decide whether to create a lead, update a contact or add an opportunity;
- the form must create several linked records (a contact, a case and a file, for example);
- you need logs, retries and alerts that a plugin or Zap doesn’t give you;
- your web app already has users and needs product sign-ups or trials to reach Salesforce.
A typical build: the form posts to a serverless function; the function checks the CAPTCHA token, validates and normalizes fields, stores the raw submission, then authenticates to Salesforce as a dedicated integration user through an OAuth server-to-server flow and calls the REST API to search, create or update. Failed calls go to a retry queue, and anything still failing raises an alert. Confirm that records created this way still go through your lead assignment rules, since that depends on how the API is called. For more on building this kind of service, see API development.
Built by Gilzor
Results we’ve shipped




Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.
Field mapping: what goes where
Map fields once, in a shared table, before anyone builds a form. This mapping works for most B2B lead forms:
| Form field | Salesforce field | Direction | System of record | Notes |
|---|---|---|---|---|
| First name, last name | Lead: First Name, Last Name | Website → Salesforce | Salesforce after creation | Last Name is required on leads; send a placeholder if your form only asks for one name field |
| Work email | Lead: Email | Website → Salesforce | Salesforce | Your main matching key. Lowercase and trim it before sending |
| Company | Lead: Company | Website → Salesforce | Salesforce | Required on leads. If you don’t ask for it, fill it from the email domain or a placeholder |
| Phone, country, state | Lead: Phone, Country, State | Website → Salesforce | Salesforce | With state and country picklists on, send values Salesforce accepts |
| Interest or product dropdown | Custom picklist | Website → Salesforce | Salesforce defines the values | Form options must match picklist values exactly, or the record can fail |
| Message | Lead: Description | Website → Salesforce | Website | Long text; strip HTML |
| Hidden: UTM source, medium, campaign, content, term | Custom lead fields | Website → Salesforce | Website (first touch) | Never overwrite first-touch values on later submissions |
| Hidden: landing page, referrer, click ID | Custom lead fields | Website → Salesforce | Website | Keep click IDs if you plan offline conversion imports to ad platforms |
| Hidden: campaign | Campaign member | Website → Salesforce | Salesforce owns campaigns | Per form or per landing page, for campaign influence reporting |
| Consent checkbox and text version | Custom fields or consent records | Website → Salesforce | Website captures, Salesforce stores | Store what was agreed, when and on which form |
| Lead Source | Lead: Lead Source | Set by the integration | Integration | A fixed value such as “Website” per route |
Map the custom lead fields to contact, account and opportunity fields in Salesforce’s lead conversion mapping too. Otherwise attribution disappears the moment a rep converts the lead.
Capture UTMs and attribution properly
Most “Salesforce doesn’t show where leads come from” complaints trace back to UTMs that never left the browser. The fix is the same on every platform:
- On the first page view, read
utm_*parameters, the click ID and the landing page from the URL, and save them in first-party storage for the session (or longer, if your consent banner allows it). - On every form, add hidden fields and fill them from that storage just before submit. Visitors often land on a blog post and convert on the contact page three clicks later, when the URL no longer carries UTMs.
- Keep first touch and last touch separately if your reporting needs both. Never let a later submission overwrite the first-touch fields.
- Never put personal data in URLs. Pass email or names only in the form body.
Common pitfalls and how to fix them
| Problem | Why it happens | Fix |
|---|---|---|
| Leads stop arriving in the afternoon | Spam bots used up the Web-to-Lead daily limit; real leads wait in the queue | Keep reCAPTCHA on, add a honeypot field, block known bad patterns before posting |
| Every submission is a new lead | Web-to-Lead and most simple flows only create; returning contacts aren’t matched | Search by email first (plugin, Zap or function), or duplicate rules with a defined action |
| Duplicate leads from one submission | Two routes on one form, such as a plugin feed plus a Zapier flow, or a double-firing tag | One route per form; document it next to the form |
| Submissions silently disappear | A validation rule, required field, blocking duplicate rule or picklist value rejects the record | Test edge cases in a sandbox, log every raw submission outside Salesforce, alert on failures |
| Leads land with the wrong owner | No active assignment rule for this route, or the API call doesn’t trigger it | One active lead assignment rule with web entries; test owner on every route |
| UTMs blank in Salesforce | Hidden fields missing, filled after submit, or cleared on page navigation | Store UTMs on landing, fill hidden fields from storage, test from an ad URL |
| Attribution lost after conversion | Custom lead fields not mapped to contact and opportunity fields | Complete the lead conversion field mapping |
| Integration breaks when someone leaves | Plugin or Zap connected with a person’s login | Dedicated integration user with only the permissions it needs |
| Form handler drops file uploads | Account Engagement form handlers don’t accept multipart/form-data | Upload files elsewhere and pass a link, or use a different route for that form |
| Sensitive data in Salesforce | Every form field mapped “just in case” | Map only what sales uses; keep free-text health, payment or ID data out of lead fields |
Spam, consent and privacy
Spam is not only noise. With Web-to-Lead it consumes your daily limit, and with API routes it consumes API calls and pollutes reports. Stop it on the website, before it reaches Salesforce: a CAPTCHA (reCAPTCHA, Cloudflare Turnstile or similar), a honeypot field, server-side validation of email format and required fields, and rate limits on your endpoint.
Consent belongs in the integration design, not only in the cookie banner. Record what the person agreed to (marketing emails, calls, texts), the wording version, the form and the timestamp, and send it to Salesforce with the lead. In the US, the Telephone Consumer Protection Act requires prior express consent for many automated or prerecorded calls and texts, and visitors from the EU or some US states bring their own privacy rules. Ask your legal counsel which consents your forms must capture, then make sure every route carries them.
When custom integration makes sense, and what it costs
For a single contact form, Web-to-Lead or a plugin add-on is enough. Custom work pays off when forms feed several objects, multiple sites share one org, leads need matching against existing accounts, or you can’t afford silent failures. In practice many teams keep Web-to-Lead or a plugin for simple forms and route only the complex ones through a function.
Our API integration cost guide breaks down where the hours go. If your website also sells online, the order side is a different integration: see the Shopify Salesforce integration guide and Stripe Salesforce integration guide.
Go-live checklist
Tick what is true for your setup before you switch the new forms on.
Salesforce website integration go-live
FAQ
How do I connect my website form to Salesforce?
Is Salesforce Web-to-Lead free?
What happens when Web-to-Lead hits the 500 limit?
How do I integrate WordPress with Salesforce?
Does Webflow integrate with Salesforce?
How do I pass UTM parameters from my website to Salesforce?
Where Gilzor fits
Web-to-Lead or a form plugin add-on is the right start for most websites. When forms feed several objects, sites share one org, or leads have to be matched, routed and logged reliably, Gilzor’s engineers in Poland and Cyprus can map the fields, build the integration and support it after launch. See Gilzor’s Salesforce integration services.
No sales pitch
Get a straight answer for your project
Tell us what you’re building. We’ll reply with options, a rough cost and timeline. If we’re not the right fit, we’ll say so.

Co-Founder of Gilzor. Works with founders and product companies on how to staff and run engineering: team extension, dedicated teams, and getting stalled projects moving again.
Gilzor · Web Development partner
Need a team for your web product?
Services
Web DevelopmentCustom websites and web apps — front-end, back-end, launch and support.→By company type
Selected projects






The team behind them





