Salesforce Web-to-Lead

What it is

Salesforce is the dominant enterprise CRM. Where sales teams keep their contacts, deals, and pipelines. Web-to-Lead is a built-in Salesforce feature that exposes a URL: you POST a form payload to it, Salesforce creates a Lead record, your sales team sees it in their queue.

It's free. It's included with every Salesforce edition from Essentials up. It has worked the same way since approximately 2006. Most people never use it because the docs are buried under three layers of "talk to your AppExchange consultant who will sell you a $99/month sync plugin."

How we use it

Form submission fans out to three destinations

Every contact form submission goes three places at once: your own database (so you own the record), an email to the team (so a human sees it now), and Salesforce (so it lands in the sales workflow). One form fill, three destinations, no copy-paste between systems.

Field mapping is documented

Salesforce custom fields have a user-visible name and an internal identifier. The internal identifiers are what the sync uses, because they stay stable when admins rename fields. The mapping between your form fields and your Salesforce fields lives in a markdown doc next to the code, so the next person to touch it does not have to reverse-engineer anything.

Local-first, so leads survive vendor outages

The local database write happens before the Salesforce push. If Salesforce is down, slow, or rate-limiting, the lead is already captured on your side. The team still gets the email. The lead still shows up in your admin. When Salesforce is healthy again, the queued leads can be re-pushed.

This is the part most "Salesforce integration" plugins get backwards. They make Salesforce the source of truth, which means a Salesforce hiccup means a lost lead. We make your database the source of truth and let Salesforce be a downstream subscriber.

Same shape works for HubSpot, Pipedrive, Zoho

The architecture is generic. A form fires an action, the action writes locally, then a downstream pusher syncs to whatever CRM the client uses. We have shipped this pattern with HubSpot, Pipedrive, and Zoho on different projects. Salesforce Web-to-Lead happens to be the cheapest and most boring option, which is why we lead with it.

What you get

• Every website lead lands in Salesforce automatically. No copy-paste, no "did anyone follow up on that?"
• Sales sees leads in their existing workflow. No new tool to learn, no new tab to keep open.
• Free. Salesforce charges $0 for Web-to-Lead. No Zapier (~$30/month per zap), no Make.com, no third-party SaaS in the loop.
• Local-first means leads survive Salesforce outages. We've never lost a lead.
• Full audit trail. Every form submission is in your database AND in Salesforce. Reconcile any time.

Where we don't use it

If a client isn't on Salesforce, this specific implementation doesn't apply, but the pattern does. HubSpot has a similar Forms API. Pipedrive has a Leads API. Zoho has webhooks. We use the same CF7 hook architecture and swap the endpoint.

For sites doing 1000+ leads/day, live synchronous POSTs become a reliability liability. At that scale you'd want a queue (SQS, or just a custom retry table) between WordPress and the CRM, so retries are managed and failures don't drop on the floor.

If the sales team requires advanced field validation, duplicate detection, or assignment rules at form submission time, the official Salesforce REST API (with proper OAuth) is the better fit. Web-to-Lead is fire-and-forget, which is the right call 95% of the time and the wrong call when you need feedback.