Connecting Webflow forms to other services

Introduction

Your website's forms often need to collect and send form submission data to other services in your tech stack, such as customer relationship management (CRM) systems, marketing automation platforms, or analytics tools. With Webflow sites, you can typically do this in either one of two ways:

1. Add custom code for form embeds provided directly by your third-party service or
2. Use native Webflow form elements and send form submission data to your third-party service

This guide provides an overview of why you might use one method or the other and the various options for connectivity when using Webflow's native form elements.

Using Webflow forms

Advantages

Webflow form elements are often preferable to embeds because Webflow forms are innately compatible with the visual design and development capabilities of the Designer. In particular:

• Webflow forms can be previewed in the Designer, whereas you can view third-party embeds only on your published pages

• Webflow forms can be styled visually with greater flexibility and control through the Style panel, whereas third-party embeds require developers to write custom CSS code to style embedded form elements

• Webflow forms can be iterated upon safely in the Designer with page branching and your staging domain, whereas changes to embedded forms may require additional steps in your external services and using separate codes in staging vs. production

• Webflow forms may be more reliable and performant because embeds typically rely on third-party scripts that inject their form after a page begins loading. Injected code can increase dependencies and load times and may cause conflicts with other scripts that need to target on-page content (such as personalization or A/B testing tools). In comparison, Webflow forms are included in a page's HTML markup and source code, making it available for a browser to load and identify more quickly.

Disadvantages

Although Webflow forms unlock greater design control, they may only be preferable for some use cases or scenarios.

• Third-party form providers often offer pre-built form templates and simplified interfaces, making it easier to create and manage forms without extensive knowledge of HTML forms. Although Webflow forms are incredibly flexible, it may be daunting or risky for inexperienced users to handle different types of input fields, build forms for accessibility, or create hidden fields to capture tracking data. 

• If you are mapping your Webflow form fields to those in a third-party form, you may need to maintain and update each separate form if there's a change in one system. If your forms undergo frequent changes, this may extend your development time or decrease the reliability and integrity of your form integrations.

• Webflow forms may not have out-of-the-box support for complex features like conditional logic, multi-step experiences, or calculations. Although it is possible to build this with custom code and developer resources, some teams prefer to use existing third-party solutions.

• Some Webflow form settings, such as email notifications and spam filtering, apply to all Webflow forms on your site. If you need these settings to vary across individual forms, it's possible to build custom functionality, but it often requires third-party tools or developer resources.

Data storage

Some organizations have strict requirements about data handling and storage, and the various options below have different implications for how form submission information is either stored in Webflow or passed to an external server, such as your intended service. The method most appropriate for you will generally depend on your compliance requirements.

Connectivity options

Form action URL

Some third-party form providers furnish form handlers that process your form data when you submit it to their service. This form handler may be a server-side script, a web service, or any other resource capable of handling and processing the form data and is represented by a URL (the "form action URL").

Webflow form settings support the ability to specify a custom form action URL. With this method, your Webflow forms will send serialized submission data directly to your form handler, bypassing Webflow's servers. Webflow will not handle or store your form data; no form submissions will be available on your Webflow Site settings page.

Forms API

Webflow supports various application programming interface (API) endpoints that allow different applications to communicate with Webflow. In particular, Webflow's Forms API will enable you to programmatically access all your form submissions or individual form submissions and send that data to your third-party service.

This method stores and retains form submission data in Webflow, which is available on your Site settings page. When you or your service send a request to one of Webflow's Forms API endpoints, Webflow responds with a copy of your form submission details as JSON data. 

Before choosing this method, it's important to note that API requests are not automatic; you will need to poll for data and initiate those requests to Webflow, so the Forms API is generally not a good fit for connections that require real-time data (instead, we recommend the following option involving webhooks). API integrations typically also require a third-party tool or developer resources. Additionally, API requests may be subject to rate limiting, although the maximum requests per minute (RPM) varies across different Webflow Enterprise project tiers.

Form submission webhook

Webflow supports various webhooks, which allow Webflow to send real-time data or notifications to another system automatically when a specific event occurs. With Webflow forms, you can create a webhook triggered by form submissions to send form data to your third-party service.

This method stores and retains form submission data in Webflow, which is available on your Site settings page. When the webhook fires (i.e., when someone fills out your form), Webflow sends a copy of that form submission as JSON data to your external system.

Before choosing this method, it's important to note that the receiving system must be capable of receiving HTTP requests, and there are potential limitations of maximum Webflow webhooks and retry attempts.

Apps and integrations

Existing Apps and integrations can help facilitate the webhook and API capabilities described above, either by handling the connection directly or by serving as middleware. These solutions may be especially preferable or convenient for teams without developer resources.

For example, Webflow's native Marketo forms integration uses a combination of Webflow's form submission webhook and Marketo's Submit Form AP to mirror a Marketo form submission. This integration method stores and retains form submission data in Webflow, available on your Site settings page. When someone fills out your Webflow form, Webflow automatically sends a copy of that form submission information to Marketo.

Another example includes the HubSpot App in the Webflow Marketplace. Among other capabilities (including improvements to managing embedded forms), the HubSpot App enables you to connect your Webflow forms to HubSpot. This integration method stores and retains form submission data in Webflow, available on your Site settings page. When someone fills out your Webflow form, Webflow automatically sends a copy of that form submission information to HubSpot.

For other services without an existing App or direct integration, you can use middleware solutions (such as Zapier and Make) to relay requests between Webflow and your third-party service. With middleware solutions, your form submission data is stored and retained in Webflow and remains available on your Site settings page. When someone fills out your Webflow form, your middleware is notified to get a copy of your form submission information, which it then sends to your other service. Although middleware solutions may help bridge a connectivity gap, they may also introduce an additional point of potential failure that can affect reliability.

Webflow Logic

Note: The publishing behavior for Webflow Logic is not currently compatible with staging domains (among other potential limitations) — making it a generally low fit for teams relying on multi-step deployment workflows.

Webflow's native Logic feature helps you manage Webflow's webhook capabilities and make API requests to other applications through automated workflows centralized in the Designer. With Webflow forms, you can create a Logic flow with a form submission trigger to make an HTTP request to your third-party service. This feature allows you to send your Webflow form data via API without needing a separate server or middleware solution. However, it may still require developer resources and some familiarity with API requests.

This method stores and retains form submission data in Webflow, which is available on your Site settings page. When the Logic flow is triggered, Webflow sends a copy of that form submission information to your external system, typically through a POST request.

Before choosing this method, it's important to note that the receiving system must be capable of receiving HTTP requests; the authorization requirements and request URL for your receiving system will depend on their API capabilities, so you'll need to reference your third-party service's API documentation for this information.

Summary

Depending on the requirements and workflows involved with your website's forms and form data, you may opt either to build them with Webflow's native form elements or to embed a form code provided by your third-party service. When you use Webflow forms, multiple methods are available for passing your form submission data to your external system, each with varying considerations for data handling, data storage, developer resources required, and potential limitations to consider.