CRM integration services connect your website to your customer relationship management (CRM) system, so every inquiry lands in HubSpot or Salesforce with the person's details and where they came from, without anyone copying it out of an inbox. There are three ways to do it: the CRM's own forms or plugin, a connector like Zapier, or a custom integration that talks to the CRM's API. For a small business, the CRM's own forms are usually enough on a standard WordPress site. A custom integration is what we'd pick when the site is custom-built or the campaign data has to arrive intact.

The choice matters more than it looks, because most of what goes wrong with a CRM integration doesn't show up as an error. The lead arrives, so everyone assumes it works. It's only months later, when someone asks which campaign brought in last quarter's customers, that it can turn out a lot of the leads have no source, or the same person is in the CRM more than once.

What does connecting your website to a CRM actually get you?

One place where every inquiry lives, with who sent it, from which page and which campaign. Sales can follow up from the record instead of an email thread, and marketing can see which channels bring in customers, not just form fills. That only works if the lead source comes across too, and that's where most setups fall short.

An inbox, Outlook included, isn't a CRM. It holds the message, but it can't tell you what stage a person is at or which ad they clicked before they wrote. HubSpot and Salesforce are the two CRMs this post covers, though others like Zoho, Microsoft Dynamics and Pipedrive connect to a website in much the same ways.

The three ways to connect a website to HubSpot or Salesforce

Each has its place, and each breaks somewhere different:

The CRM's own forms or plugin A connector like Zapier A custom API integration
Best for Standard WordPress sites, HubSpot or Salesforce forms as they come A one-way push between two tools Custom-built sites, forms that must carry campaign data, any logic
Effort to set up Lowest Low Highest
Tracking and lead source HubSpot: built in, within limits. Web-to-Lead: only what the form sends Only what you map Whatever you build, including the visitor's history
Who looks after it The vendor runs it, you own the fields Whoever set it up Your developer
Where it breaks Single-page apps, hidden fields, field types Lookups, two-way sync, silent failures Untested edge cases: empty fields, outages, duplicates

Option 1: the CRM's own forms and plugins

This is the native route, and the least effort. In HubSpot that means embedding HubSpot's forms on your pages, or installing its WordPress plugin, which is the usual HubSpot WordPress integration. In Salesforce it means Web-to-Lead, a form Salesforce generates that posts straight into your leads.

With HubSpot, visitor tracking comes built in. Web-to-Lead only records what the form sends, so campaign tags need fields of their own. Either way, nobody has to write code.

HubSpot also has a middle option that a lot of people don't know about: it can capture submissions from your site's own HTML forms, on every plan. The catch is in the details of HubSpot's guide to non-HubSpot forms. Capture only works if HubSpot's tracking code loads, and it doesn't work on most single-page apps, where the page isn't reloaded as you move around the site, which is how a lot of modern React sites behave. It also ignores hidden fields, which are a common way to carry the UTM parameters (the campaign tags on a link that say where a click came from) along with the form, and every captured field maps only to a single-line text property in HubSpot, so a dropdown or a date arrives as plain text.

So capture is fine for a simple contact form on a regular WordPress site, but we wouldn't rely on it anywhere the campaign data is the point.

Salesforce's Web-to-Lead has a limit worth knowing before you rely on it. According to Salesforce's help page on Web-to-Lead limits, it creates up to 500 leads in 24 hours. Anything over that waits in a queue it shares with Web-to-Case, and once that queue holds 50,000 requests, new ones are turned away. Most small businesses will never get 500 real leads in a day, but a spam bot hammering an unprotected form can, and then real inquiries wait behind it.

If the CRM change is happening as part of a new site, the forms and their connections belong on your website migration checklist, because they're one of the things that quietly stop working after a move.

Option 2: a connector such as Zapier

You don't need one to connect a website to a CRM. Still, a connector like Zapier or Make is good for a simple one-way push between two tools that nobody wants to build: a form tool sending entries into the CRM, or new CRM contacts going into an email list.

The trouble starts when a connector becomes the backbone of how leads move, because of who owns it. It usually lives in one person's account. When that person leaves, or one of the two tools changes a field, the Zap can stop and nobody notices until leads go missing.

It also runs out of road when the logic gets more involved. Looking up whether a contact already exists before writing it, deciding what to update and what to leave alone, or keeping two systems in step both ways is where a connector gets fragile, and where we'd stop and build it properly.

Option 3: a custom integration through the CRM's API

Your site's server talks to the CRM's application programming interface (API) directly, so it can look the contact up, update or create it, and attach the inquiry. It's the most work to build, but it can do pretty much whatever your process needs.

On a custom-built or single-page site it's the main alternative to HubSpot's embedded forms, and the only one that gives you full control over the data. The same approach works with Salesforce's API, for anyone who has outgrown Web-to-Lead.

There's a catch with HubSpot, though, and it's easy to miss. If your form submits on the server, as a custom integration does, and doesn't pass along HubSpot's tracking cookie, HubSpot may not be able to link the visitor's earlier visits and page views to the new contact. For HubSpot to credit a contact to an ad, its ads attribution guide says a custom form sending data through the Forms API has to include the page URL and the tracking cookie. None of that rules out a custom form, though. A little custom code can read HubSpot's cookie and send it with the submission, which we've done for clients who needed page views and ad attribution. Leave it out, as we do on our own site, and that history can be lost.

Rate limits are rarely a problem at small-business volume. As of 2026, HubSpot's API usage guidelines allow a private app on a Free or Starter account 250,000 calls a day, which no contact form will get near, though a bulk import or a nightly sync of a big list can.

Our own site is a working example. The contact, partnerships and speed report forms on ez-digital.com write to HubSpot's free CRM through its API. Each submission searches for the contact by email first, updates only the fields the form actually filled in (so an empty field can't blank a value already in HubSpot), or creates the contact with a lifecycle stage (HubSpot's label for where someone is, from lead to customer) and a lead source that names the form it came from. A note with what they sent goes on the record. It never moves an existing contact's lifecycle stage, so a customer who fills in the contact form stays a customer, and it runs after the email has gone out, so a visitor never waits on HubSpot and a HubSpot outage only gets logged.

We went with the API rather than HubSpot's own forms for two reasons. The forms look like the rest of the site, not an embedded widget, and we can attach whatever data the record needs, such as campaign tags we've kept in a cookie of our own. We don't pass HubSpot's tracking cookie on our own forms, so the page-view history doesn't come across. For us that's fine, since the lead source matters more than which pages they read first.

When a site is custom-built or the data has to arrive complete, this is how we'd connect it, and it's a big part of our API integration work.

Which option fits your project

Three questions usually settle it, and for most small businesses the answer is the CRM's own forms:

  1. What is the site built on? A regular WordPress site can use HubSpot's plugin or embedded forms. A custom-built or single-page site rules out HubSpot's form capture, so it's HubSpot's embedded forms or a custom integration.
  2. What does the CRM need to receive? If it's a contact with a name, an email and a message, the CRM's own forms will do. If it's a contact plus campaign data, a note, a deal or a stage, or the record has to be looked up first, it's a custom integration.
  3. Who will look after it? A connector is only as reliable as the person who owns the account. If nobody on your side wants that job, don't build the lead flow on one.

Our default is the CRM's own forms when the site and the data are simple, because there's nothing to maintain. We'd recommend against a custom integration when the forms are standard and nobody will ever report on lead source, since you'd be paying for precision nobody uses. On a new site or a redesign, though, the CRM connection costs least when it's planned in from the start, alongside the forms themselves, which is how we handle it in our web design projects.

What breaks: duplicate contacts, lost lead sources and fields that don't map

Most of the trouble is pretty predictable, and since none of it throws an error, it tends to be found late.

Duplicate contacts. HubSpot deduplicates contacts automatically by email address, and companies by domain. That's sensible, but it means the same person writing in from a work email and then a personal one becomes two contacts. There's a less obvious version too: when a submitted email matches nobody, HubSpot may fall back on the cookie in the visitor's browser and update the contact it already knows from that device, so a shared office computer can overwrite one person's record with another's. If forms get filled in on a shared computer, like a front desk or a trade-show tablet, check how HubSpot handles a new email from a known device.

Lost lead sources. Hidden UTM fields that HubSpot's capture tool ignores, a server-side form that doesn't pass the cookie, or a connector that was never told to map the campaign fields all end the same way: a lead with no source, which nobody can credit to the campaign that paid for it. Then there's the visitor who lands from an ad, reads three other pages and only then fills in the form, by which point the campaign tags may no longer be in the address bar.

We handle that with a cookie of our own. When someone arrives with campaign tags, the site saves them, and the form reads them back whenever it's sent, however many pages later. How long that cookie lasts, and which campaign wins when the same person comes back from a different one, we decide project by project. Keeping the first credits whatever introduced them, keeping the latest credits whatever brought them back, and either can be right depending on what the reporting is for.

You can test this yourself in two minutes. Open your site from a link with a made-up campaign tag on the end, click to another page, send an inquiry, and see what the CRM record says about where it came from.

Fields that don't map. This usually starts small, with a dropdown whose options don't match the CRM's. The nastier version is an empty form field overwriting a filled one, so the second time someone gets in touch, their phone number disappears. So we decide field by field what the form sends and what the CRM keeps, and only send what was actually filled in.

Changes on the CRM side. The worst problems we've run into didn't start on the website at all. A Salesforce admin renames a field or changes how an object is set up, nobody tells the developers, and the integration starts failing from that day on. The other one is the CRM's API timing out, so a submission simply never arrives. That's why the CRM is never the only place a lead is kept. Every submission also goes into a database, a spreadsheet or an email, depending on the project, so if the CRM rejects it or doesn't answer, the lead can still be recovered.

If you're an agency whose reporting depends on lead sources reaching a client's CRM, this is the part to get right, and it's the first thing we look at in our development partner work.

Data enrichment: shorter forms and better sales data

Enrichment tools take a work email address and look it up in a company database to fill in the rest: the company, its size and industry, often the person's job title. The visitor has fewer fields to fill in, and sales gets a fuller record than any form would collect.

HubSpot has this built in as form shortening. On forms made in its updated form editor, the visitor sees the email field first, and HubSpot hides the fields it can already fill from its enrichment data. It needs a Starter plan or higher, and since September 2025 it hasn't used HubSpot Credits. ZoomInfo's FormComplete works on the same idea, with ZoomInfo's data behind it: the form asks for a business email, FormComplete fills in the rest, and it rejects an invalid address as soon as it's entered.

With a custom integration, enrichment doesn't have to happen in the form at all. The server can call an enrichment API once the inquiry comes in and add what it finds before writing to the CRM, so the visitor never waits on a lookup.

There are a few limits worth planning for, though:

  • Personal email addresses don't enrich. HubSpot's enrichment guide says a Gmail or Yahoo address won't be enriched, so a shortened form needs a way to ask for the missing fields when the lookup comes back empty.
  • Enriched data can be out of date. People change jobs, so what the person typed should win over what a database says.
  • Privacy. You're adding data about a person that they didn't give you. HubSpot's own guide notes that enrichment may need extra compliance steps, so it belongs in your privacy policy, and it's worth a check against the privacy rules your business is under.

For a B2B site where sales follows up on every lead, we think it's usually worth it. Where most inquiries come from personal addresses, as with many local service businesses, there's much less to gain.

If you run HubSpot and Salesforce together

It's common for marketing to live in HubSpot and sales in Salesforce.

HubSpot has its own Salesforce integration that syncs them, but check the plans first. As of 2026, according to HubSpot's guide to connecting HubSpot and Salesforce, it needs a Professional or Enterprise HubSpot subscription, plus a Salesforce edition with API access or Salesforce Professional. Salesforce Group Edition isn't supported.

Before switching the sync on, decide which system owns which field. If both can change a contact's phone number or its stage, they'll take turns overwriting each other, and it's much easier to settle that on paper than to untangle it afterwards. If you're not sure which system should own which data, that's worth settling in a short consulting review before the sync goes live.

What CRM integration services cost

It depends almost entirely on what has to happen between the form and the CRM, which is why we estimate each one rather than quote a figure. The same request can be a day's work or several weeks.

These are the things that usually decide it:

  • The number of forms and what each carries. A single contact form with four fields is quick. Five forms, each with its own fields, campaign data and routing, is a different job.
  • The logic. A form that only creates a contact is simple. One that looks the person up first, decides what to update and routes the lead to the right salesperson takes a good deal longer to build and test.
  • The CRM's own setup. Custom properties and pipelines that have to exist before the integration can write to them.
  • Cleaning the existing data. If the CRM already has duplicates or leads without a source, it's worth fixing before new data piles on top.
  • Testing. Every path, including what happens when the CRM is down or rejects a record.

Then there are the running costs: the CRM tier a feature needs (the HubSpot and Salesforce sync above is a good example), any connector or enrichment subscription, and keeping the integration working as the CRM's API changes. On a bigger build, the CRM connection is often one of the lines that moves the estimate most, and our breakdown of web app costs shows where integrations sit among the rest.

Run the two-minute test above, then list your forms and what each should create in the CRM, and get in touch. We'll tell you which of the three options fits, and give you an estimate for it.