Connecting Your Website and CRM: Forms, HubSpot and Inquiries, Done Properly

By Edip Kilinc, founder of Webwavers. Published October 31, 2026. Last updated October 31, 2026. Reading time: about 16 minutes. The legal notes in this text are not legal advice.

Short answer: You connect website and CRM cleanly when every inquiry arrives in the CRM complete, with source and language and without duplicates, and when you know what happens if something goes wrong. There are four ways to do it: embed the native CRM form, send your own form via API, use a webhook with middleware, or have forms captured automatically. Which one fits depends on your design requirements, data model and data protection needs.

The key points in brief

• Start with the data model, not the tool: Which fields does your sales team really need, and what should they be called in the CRM?
• Embedded CRM forms are fast, custom forms fit the design better. Both can run cleanly.
• Automatically captured forms have limits. Check them before you rely on them.
• Plan for failure cases from the start: spam, a CRM outage, duplicate contacts, missing required fields.
• Data protection belongs in the architecture: legal basis, information, contract with the CRM provider and how you handle tracking cookies.

Table of contents

• What "connected cleanly" means
• Before the tech: data model and process
• The four ways compared
• Way 1: Embed a CRM form
• Way 2: Your own form via API to HubSpot
• Way 3: Webhook and middleware
• Way 4: Automatically captured forms
• Fields, source, language and attribution
• Spam, failure cases and monitoring
• Data protection in the integration
• Showing a HubSpot blog on the Webflow website
• Test plan before launch
• Industry examples: software, energy, real estate
• When you don't need an agency
• How we do it
• FAQ

What "connected cleanly" means

Many websites have a form that somehow sends emails, and a CRM into which someone transfers inquiries by hand. That works as long as there is little going on. Once campaigns run or several people work in sales, inquiries get lost, land in the system twice or arrive without a source, so nobody knows which effort brought them in.

Connected cleanly means: every inquiry lands in the CRM automatically, with all the fields sales needs, with source, page and language, without duplicates and with a traceable consent or legal basis. And: you find out when something doesn't work. The design and structure of forms themselves, meaning number of fields, texts and submit button, are covered in our article Optimizing Inquiry Forms. This guide is about what happens behind the submit.

Before the tech: data model and process

The most common cause of chaos in a CRM is not a technical error but an unclear data model. Before you connect a form, you settle four things.

1. Which objects get created? A contact, a company, a deal? With HubSpot, the Forms API lets you assign fields to different object types, such as contacts (0-1) and companies (0-2) (HubSpot, Submit data to a form). Think about whether an inquiry only creates a contact or a deal as well.

2. Which fields are required? Every additional field lowers the completion rate, and every missing one creates work for sales. Separate "we need it right away" from "we'll clarify it in the conversation". Art. 5(1) GDPR (DSGVO) also requires data minimization: collect only what you need for the purpose (Art. 5 DSGVO).

3. What are the fields called in the CRM? Define internal field names up front and record them in a mapping table. A field "Company" on the website, "Account" in the CRM and "Organization" in the newsletter tool is the recipe for duplicates.

4. Who does what with the inquiry? Who gets the notification, how fast is the reply, what happens outside business hours? The best integration is useless if the inquiry lands in a mailbox nobody reads.

A simple mapping table can look like this:

Field in the form	Field in the CRM	Required	Note
First name	First name	yes	Store separately from last name
Last name	Last name	yes
Email	Email	yes	Key for duplicate detection
Company	Company	yes for B2B	Create as a company object
Message	Inquiry text	no	As a note or property
Reason for inquiry (selection)	Inquiry type	yes	Dropdown instead of free text
Page of the form	Source URL	automatic	Passed from the context
Language	Language	automatic	From the language version
Consent/notice	Legal basis	automatic	Record text and timestamp

The four ways compared

Way	How it works	Strengths	Weaknesses	Fits
1. Embed a CRM form	The form is built in the CRM and inserted into the page with embed code	Fast, fields and logic in the CRM, little development	Less design freedom, third-party script on the page	Landing pages, quick campaigns
2. Own form via API	The website form sends directly to the CRM's API via script	Full design freedom, clean fields and context	Needs development and maintenance, error handling to build yourself	Brand websites with high design standards
3. Webhook plus middleware	The website CMS reports the submission to an automation service, which writes it to the CRM	Flexible, several targets possible, no own server	Extra service, extra cost, additional data processing	Several systems, changing workflows
4. Automatic capture	The CRM detects normal HTML forms on the page and captures submissions	Hardly any development effort	Many restrictions, dependence on the tracking script	Simple forms as a stopgap

None of these ways is better in general. For a clean result, what counts is that you choose the right one and cover the failure cases.

Way 1: Embed a CRM form

The fastest start is the CRM's native form. You build it in the CRM, copy the embed code and put it into a code block on the page. Marketing maintains fields, required entries, conditions and notifications in the CRM itself. That is handy when campaigns need to go live fast.

The limits: The look rarely matches your design exactly, and the form loads a script from the CRM provider. From a data protection point of view, that is an external script you have to include in your inventory of services. Whether it may load before or after consent depends on the configuration and the legal assessment. The technical side is covered in the guide Tracking Consent under the TDDDG.

Way 2: Your own form via API to HubSpot

If the form should match the design, you build it in the website and send the data to the CRM via API. For HubSpot, there is the Forms API endpoint for submitting data:

POST https://api.hsforms.com/submissions/v3/integration/submit/{portalId}/{formGuid}

According to the HubSpot documentation, you need the portal ID and the form ID in the path, and in the body a fields array with up to 1,000 entries. Each entry consists of object type, name and value. In the optional context, you can pass hutk (the tracking token), pageUri (the page of the form), pageName and ipAddress, among others. According to the documentation, the endpoint requires no authentication and supports CORS requests. When limits are exceeded, the API responds with HTTP 429, and with 400 and an error list for validation errors (HubSpot, Submit data to a form).

A call in simplified form looks like this:

POST /submissions/v3/integration/submit/PORTAL_ID/FORM_GUID { "fields": [ { "objectTypeId": "0-1", "name": "email", "value": "name@company.de" }, { "objectTypeId": "0-1", "name": "firstname", "value": "Mara" } ], "context": { "pageUri": "https://www.company.de/contact", "pageName": "Contact" }, "legalConsentOptions": { ... } }

Send consent details along. The API has an optional legalConsentOptions object. In it, you can pass either a consent (with consentToProcess and the displayed text) or a legitimate interest (with legal basis and text). This helps record the data protection details in the CRM. Which legal basis applies to you is not a developer question.

Where the script runs. The request can be sent directly from the browser or via a small server step in between. The second variant gives you more control over spam filters, retries on errors and keeping credentials hidden for authenticated endpoints. For larger projects, this intermediate step is worth it.

Maintenance. A custom integration is code that has to be maintained. If the CRM changes a field or an endpoint, the integration has to be adjusted. Plan for that in the maintenance contract, see the page Maintenance.

Way 3: Webhook and middleware

In Webflow, webhooks report events to a target server. For forms, there is the form_submission event. According to the documentation, the payload contains, among other things, the form name, the site ID, the submitted data, a schema of the fields, the timestamp, the form element ID and the locale ID of the language the form was submitted from. For pages without localization or in the primary language, the locale ID is empty (Webflow Developers, form_submission). That is valuable because it lets you carry the lead's language into the CRM, as described in the guide on the multilingual company website.

The webhook alone doesn't write anything into the CRM yet. That takes a receiver: an automation service, a serverless function or your own service. It accepts the data, cleans it up, maps it to the CRM fields and forwards it. The advantage is flexibility: you can serve several targets (CRM, notification, spreadsheets) and build in rules.

Keep the costs and risks of the intermediate step in mind:

• The automation service processes personal data on your behalf. For data processing on behalf of a controller, Art. 28 GDPR (DSGVO) requires a contract with defined content (Art. 28 DSGVO). Check whether the provider offers one.
• Additional services are additional points of failure. Build in retries and notifications on errors.
• Factor in license costs and limits of the service before you commit.

Way 4: Automatically captured forms

HubSpot offers to capture forms on external pages automatically ("Non-HubSpot Forms"). The tool detects HTML forms by their form tag and stores submissions in HubSpot. The prerequisite is that the HubSpot tracking code is installed on the page and the feature has been enabled in the settings (HubSpot, Non-HubSpot-Formulare).

That sounds convenient, but it has clear limits:

• Only static HTML in form tags, with an email field and a standard submit button.
• No iframe, no JavaScript on the submit event, no single-page apps. The form has to be present when the page first loads.
• No hidden fields and no sensitive fields such as credit card numbers.
• If the tracking script doesn't load, for example because of script conflicts or browser extensions, submissions are lost.
• Every click on submit creates a submission, even with incomplete entries. With validation on the page, this produces both partial and full submissions.
• Data is mapped only to single-line text fields, manual assignment is not possible, and matching happens automatically based on field name and label.
• All submissions assigned to the same cookie end up with the same contact, even if different email addresses are used.
• There is a maximum of 10,000 non-HubSpot forms per account.

For a brand website project with demands on data quality, this is usually only a stopgap. As an emergency fix for an existing form, it can be useful as long as you know the restrictions.

Fields, source, language and attribution

A lead without context is worth half as much. You should pass along the following extra information:

Information	Purpose	How
Page of the form	Which page convinces	pageUri or pageName in the context (HubSpot API)
Language	Correct form of address, who is responsible	Locale ID of the webhook with Webflow Localization
Form type	Demo request, contact, download	Separate field or separate form
Campaign parameters (UTM)	Channel and campaign	Read on page load, carry into the form
Additional details	Property ID, plan, system	Hidden fields (not with automatic capture)

On UTM parameters: they are in the URL and can be written into hidden form fields on page load. Check whether anything is stored in the browser for this, because then § 25 TDDDG (German Telecommunications Digital Services Data Protection Act) applies. Simply reading the URL at submit without storing anything on the end device is technically easier to justify, but you leave the assessment of the individual case to your data protection officer.

On the HubSpot tracking token hutk: it comes from the hubspotutk cookie, which identifies the visitor and is used to merge contacts on submit. HubSpot lists this cookie among the necessary cookies in its documentation (HubSpot, Cookies). Whether that counts as strictly necessary under § 25(2) TDDDG is a legal question. The German Data Protection Conference (DSK) reads the exception narrowly and explicitly does not accept business model interests as a justification (DSK, OH Telemedien 2021). So have the question settled before go-live instead of relying on the provider's classification.

Spam, failure cases and monitoring

An integration shows its quality only when something goes wrong. Plan for these cases from the start.

Spam. Forms attract automated submissions. Combine several measures: a hidden bait field (honeypot), server-side validation, a timing check and, where appropriate, a captcha service. Note that a captcha service is itself an external service and belongs in your data protection review. Without spam protection, the CRM fills up with junk and sales loses trust in the data.

CRM unreachable. What happens to an inquiry if the CRM briefly doesn't respond? It must not be lost. Buffer it and try again, or additionally send a notification by email. The HubSpot API responds with HTTP 429 when limits are exceeded. Your code should react to that with a retry.

Validation errors. If the API responds with 400, the response contains an error list. Log it and notify someone. Typical causes are wrong field names or invalid values in dropdown lists.

Duplicate contacts. The email address is usually the key. Check how your CRM handles the same address, and decide whether a second inquiry updates the existing contact or creates a new record.

Monitoring. Set up a simple check: every week, count form submissions on the website and new entries in the CRM. If they differ, something is wrong. This should not depend on one person's attention.

Data protection in the integration

Here is an overview of the points that technically belong in the project. The legal assessment stays with your data protection officer or your lawyer, and this is not legal advice.

Legal basis for the inquiry. Art. 6(1) GDPR (DSGVO) names, among others, processing for pre-contractual measures at the request of the data subject (point b), consent (point a) and legitimate interests (point f) (Art. 6 DSGVO). Which one fits depends on the purpose: a specific request for a quote is something different from joining a newsletter list. Separate these purposes technically, for example with a separate, unchecked newsletter option.

Information at the form. Art. 13 GDPR (DSGVO) requires that, at the time of collection, the controller, purposes, legal basis and recipients, among other things, are named (Art. 13 DSGVO). A notice with a link to the privacy policy right at the submit button is common. The CRM and, if there is one, an automation service belong in the information as recipients.

Contract with the CRM provider. If the provider processes data on your behalf, you need a data processing agreement under Art. 28 GDPR (DSGVO). The same applies to middleware services. For providers outside the EU, the question of third-country transfers comes on top, as described in the guide on Tracking Consent under the TDDDG.

Retention period and deletion. Art. 5(1) GDPR (DSGVO) requires storage limitation. Define how long inquiries stay in the CRM and how deletions work. A CRM that never cleans up becomes a data protection risk.

Sensitive details. Only ask for what you need. Free-text fields invite people to write more than necessary. A note not to enter sensitive data can make sense.

You'll find details on cookie banners and tracking in the article Using Cookie Banners Correctly and in the glossary entry on GDPR (DSGVO).

Showing a HubSpot blog on the Webflow website

A common question from practice: Marketing publishes the blog in HubSpot, and the company website runs on Webflow. How do the articles get onto the website? There are basically three ways, which differ in effort and result.

Way	Description	Advantage	Disadvantage
Blog stays in HubSpot	The website links to the HubSpot blog, e.g. on a subdomain	Little effort, editorial work stays in HubSpot	Two systems, design and SEO separated
Sync into the website CMS	A script or service transfers articles from HubSpot into the website's CMS	Everything under one domain and in the website design	Technical effort, maintaining fields, images and updates
Display via interface	The website loads articles at runtime through an interface	No double maintenance	Dependent on the interface, check SEO and load time

Which way holds up is decided by editorial workflow, SEO goal and budget. Before building, clarify where the articles should live for search engines, so no duplicates arise, and who maintains changes. There is no general how-to, because the answer depends on the setup.

Test plan before launch

With this plan, you check the integration before customers use it:

1. Success case: Fill in all required fields, submit. Check in the CRM: contact created, fields mapped correctly, source and language present, notification triggered.
2. Required fields missing: Submit without an email. The error message is understandable, and nothing is created in the CRM.
3. Invalid values: Wrong email address, overly long entries, special characters and umlauts. Check how they display in the CRM.
4. Submit twice: Two times with the same email. Update or duplicate, as planned?
5. Spam test: Fill in the bait field. The submission is not accepted.
6. Simulate a CRM outage: Enter a wrong portal ID. The inquiry is not lost, and an error message or notification appears.
7. Languages: Submit in every language version. The language arrives correctly in the CRM.
8. Consent: Submit without agreeing to optional purposes. No newsletter status is set.
9. Network tab: Check which third-party connections arise on load and on submit, and whether they match the data protection documentation.
10. Notification: Does the internal email or task reach the right team, even outside business hours?

Industry examples: software, energy, real estate

IT and software. Demo forms often need company size, use case and timeframe so sales can pre-qualify. A mapping to contact, company and deal fits this. Keep in mind that many fields lower the completion rate, see Optimizing Inquiry Forms. You'll find more on the industry at IT, Software and SaaS.

Energy. Inquiry forms for projects or consulting are often more complex, with a choice of system or service. Dropdown lists instead of free text make further processing easier. More at Energy.

Real estate. Property inquiries need the link to the property: a property ID as a hidden field, so sales knows what it's about. That works with custom forms and API integration, not with automatic capture, which doesn't support hidden fields. More at Real Estate.

When you don't need an agency

If you have a simple contact form, use a CRM with a native form builder and the design doesn't bother you, embedding the CRM form is enough in many cases. A technically capable marketing team can do that itself. You need support when the form has to match the design, when several systems are involved, when languages, sources and objects should be passed along cleanly, or when a relaunch is coming up and the integration is being rebuilt anyway.

How we do it

At Webwavers, a project follows the steps on the process page: first call, onboarding with briefing, strategy session, three moodboards, design in Figma, development and launch with training, with a dedicated project lead, your own Slack channel and a feedback round after every milestone. Depending on the project, development happens in Webflow, Framer or WordPress.

The CRM integration is not a separate step there. So bring to the first call which CRM you use, which fields your sales team needs and who handles the inquiries. Get the scope, test plan and responsibility for maintenance named in writing before you commission anything. The question "Is this worth it for us?" is finally answered by your effort without the integration: How many inquiries get lost today or are transferred by hand? You'll find more about our scope of services on the Web Development page. Webflow is our focus, but we advise neutrally on which system fits your CRM.

If you want to talk about your integration, use the contact page.

FAQ

Is an agency worth it if we need forms and CRM connected cleanly?

That depends on your effort. Check how many inquiries are transferred by hand or lost today, and whether design and data quality justify a custom form. Bring the topic to the first call and get the scope, test plan and maintenance responsibility named in writing.

How do I connect a Webflow form to HubSpot?

You have three options at its core: embed the HubSpot form, send the Webflow form via script through the HubSpot Forms API, or send the Webflow webhook form_submission to an intermediate service that passes the data on to HubSpot. The choice depends on design requirements, error handling and data protection.

Which is better: an embedded CRM form or your own form with the API?

The embedded form is faster and easier to maintain, while your own form fits the design better and gives more control over fields and context. Both can run cleanly if failure cases and data protection are thought through.

Can HubSpot capture forms on my Webflow site automatically?

Yes, through the feature for non-HubSpot forms, if the tracking code is installed. It has limits, though: no hidden fields, only static HTML, dependence on the tracking script and partial submissions. For demanding projects, a targeted approach is usually better.

How do I get the language and source of an inquiry into the CRM?

You pass the source through the page URL in the HubSpot API context or through hidden fields. With Webflow Localization, the language comes from the locale ID in the webhook payload. You map both to the CRM fields in the mapping.

Do I need a contract with the provider for the CRM integration?

If the provider processes data on your behalf, Art. 28 GDPR (DSGVO) requires a data processing agreement. That also applies to intermediate services. The legal assessment of an individual case is legal advice and belongs with your data protection officer.

What happens to inquiries if the CRM is briefly unreachable?

That depends on the error handling. A clean integration buffers the inquiry, retries the submission and notifies someone. Test this before launch with a deliberately wrong portal ID.

Sources

• HubSpot, Submit data to a form (Forms API v3)
• HubSpot, Non-HubSpot-Formulare verwenden (Using non-HubSpot forms)
• HubSpot, Cookies, Sicherheit und Datenschutz (Cookies, security and privacy)
• Webflow Developers, form_submission Webhook
• Art. 5 DSGVO (Art. 5 GDPR)
• Art. 6 DSGVO (Art. 6 GDPR)
• Art. 13 DSGVO (Art. 13 GDPR)
• Art. 28 DSGVO (Art. 28 GDPR)
• DSK, Orientierungshilfe für Anbieter von Telemedien (OH Telemedien 2021) (DSK guidance for telemedia providers)