Integrations and Marketplace Apps

The documented rules for who can install an app are short.

The installation of an app proceeds in the same order each time.

A scope is the unit of permission in the Data API. The convention is resource:read and resource:write, for example forms:read, cms:read, cms:write, sites:read and custom_code:write. The full list and the rules for tokens are on Data API Authentication and Scopes. For an installation decision the useful questions are these.

A practical habit for Fernbrook is a one-page register that lists each connected app, the scopes that it holds, the sites that it can reach, the owner on the garden’s staff and the date of the last review. When a staff member leaves, the register shows which tokens must be removed. The scopes that an app holds are also visible to the app developer in the app settings, and the Marketplace guidelines warn that changing the OAuth URL before an update is approved produces a scopes mismatch error for users, which is a reason to expect a short delay when an app asks for more access.

Source: Apps: Register an app and Apps: Submitting your app.

An app that changes the published page usually does so through the custom code endpoints of the Data API, which accept only OAuth app tokens. It registers a script and applies it to a site or page. Applying scripts with a PUT replaces the whole list, so a well-behaved app reads the list, adds its entry and writes it back. When two apps both manage scripts, the second can erase the first if it is careless. After installing an app that adds a script, open the site’s custom code settings and the page source of the published site, and confirm that your own head and footer code are still there. The mechanism is described on Data API: Assets, Forms and Custom Code.

Site settings, in the Integrations tab, has a Google Analytics field that takes a GA4 measurement ID. On 2026-10-28 Webflow’s article states that only GA4 measurement IDs are accepted; a site that still shows a UA- tracking ID belongs to the retired Universal Analytics and must be migrated in Google Analytics first. After the ID is saved and the site is published, Webflow inserts the Google tag in the head of every page. The same article advises placing the tag in only one place, either the field or the custom code, so that the tag does not fire twice.

The tag that results is the standard Google tag. This is the shape of what ends up in the page, with a placeholder ID.

Source: Webflow Help Center: How do I connect my Webflow site to Google Analytics?.

Google site tools for Webflow is a Marketplace app made by Webflow. It connects Google Analytics 4, Google Search Console and Google Tag Manager through one Google sign-in and can add a Tag Manager container without code. It holds the authorization to both accounts, so it follows the review rules above: authorize it for the Fernbrook site only, sign in with a Google account that belongs to the garden and not to a person, and remove the connection when the person who made it leaves. The listing is at https://webflow.com/integrations/google-site-tools-for-webflow.

The third option is to paste the container snippet into the site’s custom code. A Tag Manager container then holds the GA4 tag, a Facebook pixel, a Hotjar script and so on, and the marketing manager changes them without asking the webmaster to edit the site. The cost is that the container becomes a place where arbitrary code can be added by anyone with access to it. Treat container access like Designer access.

The container has two parts, a script for the head and a noscript iframe for the start of the body. Webflow’s custom code settings have a head box and an end-of-body box. The noscript fallback is optional on a site that already requires JavaScript, and it is only valid HTML in the body, so many sites paste only the head part into the site-wide head code.

Source: Webflow Help Center: Custom code in head and body tags and Google Tag Manager: Custom tags.

Custom code is limited to 50,000 characters per head or footer box, which a container snippet uses a tiny part of, and it runs on the published site only. The Designer canvas does not run it, and the preview and comment modes render on a canvas.webflow.com host that a content security policy must allow. To see a tag working, publish to the staging domain and use the Tag Manager preview mode or the Realtime report of GA4. The Custom Code: Head, Footer and Embeds page describes the boxes in detail, and Third-Party Libraries and Scripts covers loading other scripts.

A published Webflow form submits through the Webflow form handler and shows the success state without a page reload. A tag manager sees that only if the page sends an event. The simplest method is a custom event pushed to the data layer from the form’s success handling. Because the exact moment depends on how the form is configured, the Fernbrook snippet listens for the form’s own submit, which fires before the success message and is good enough for a count of attempts.

Source: Browser API: wf.ready for the readiness model, and Google Tag Manager: Custom tags for loading scripts in a tag manager. The submit listener itself is plain DOM and not a Webflow API.

The data-name attribute is what Webflow writes into a form from its name in the Designer, so naming each form clearly in the Designer is also naming it for analytics. See Forms for the generated markup.

If the garden uses a consent management platform (CMP), the platform’s callback should call the Webflow methods when the visitor makes or changes a choice. The documentation’s general pattern is the following, shown here in the shape used by the page, with the garden’s own fernbrookConsent object standing in for a platform’s event.

Source: Browser API: Site tracking and consent management.

The same page publishes samples for OneTrust, which reads the OptanonConsent cookie and reacts to the OneTrust.OnConsentChanged event, and for TrustArc, which reads a stored preference object; it states that Webflow does not support those samples. Read them as examples of the callback pattern and test them on the staging domain.

A small site can do without a platform. The documentation’s second example builds a banner in the Designer, hides it when a choice is stored and shows it otherwise, with Accept calling wf.allowUserTracking({ activate: true }) and Decline calling wf.denyUserTracking(). The Fernbrook version below keeps the logic and adds what a multilingual site needs: the text comes from the locale in the URL, and the Google tag is loaded only after acceptance. Because the banner is part of the page, its text should be a localized element rather than a string in the script; the script here carries the strings only to stay self-contained.

Source: Browser API: Site tracking and consent management and Browser API: wf.ready.

To check the result, open the browser’s developer tools on the published staging page and run wf.getUserTrackingChoice();, which is the check the documentation recommends. A cleared browser shows no stored choice, and after the Accept button it returns the allow value.

Several points need care.

On 2026-10-28 the platforms' own pages describe these building blocks.

The details change as the platforms change their apps. When a trigger is missing or its field list is old, the platforms' recommendation, repeated in their own forums, is to run the trigger once in test mode and submit the form again so that the platform reads the current fields. Each Webflow form needs a unique name, because both platforms identify a form by name.

Source: Zapier: Webflow and Webhooks by Zapier, Webflow blog: marketing automation hub with Zapier and Make: Webflow app help.

When the native trigger of a platform does not fit, a Webflow webhook can call any HTTPS URL. The webhook is created with the Data API, needs a site token or an app token with the forms:read scope for the form trigger, and can be limited to one form with a filter on the form name. The Data API allows at most 75 webhooks per trigger type per site. The destination must answer with status 200; any other status, a redirect, a certificate error or a timeout counts as a failure, Webflow retries three more times at ten-minute intervals, and then deactivates the webhook and sends an email. The secret key, when present in the response, appears only for webhooks created with a site token from the Dashboard, and it must be stored securely.

Create a Fernbrook webhook that sends enquiry-form submissions to a Zapier catch hook. The token and the site ID come from the environment, and the URL is a placeholder.

Source: Data API: Working with webhooks.

Webflow then sends a JSON body with the headers Content-Type: application/json, x-webflow-timestamp and x-webflow-signature. The structure of a form submission event, condensed and with Fernbrook data, is this.

Source: Data API: Working with webhooks.

In Zapier the Catch Hook trigger shows these fields, with the data entries as separate values, so a later step can map Email to a mail action or Group size to a spreadsheet column. In Make the custom webhook module learns the structure from the first request, after which the fields appear in later modules. The Fernbrook scenario then has three steps: post a message to the garden’s team chat with the group size and language, append a row to a bookings sheet, and send an acknowledgement in the language the visitor picked. The language comes from a hidden form field, set from the locale of the page, so that the acknowledgement is Spanish for /es and German for /de.

Dashboard-created webhooks carry no signature headers, so they cannot be verified in the way described below. If a request must be trusted, create the webhook through the API with a site token or an app and verify it.

A catch-hook URL is a secret path and not an authentication. Anyone who learns it can post to it. For a webhook that creates records or sends messages, put a verifying step in front. Webflow signs the request with an HMAC-SHA256 of the timestamp, a colon and the raw body, using the webhook’s secret key, and expects receivers to reject requests older than five minutes. A small relay, which the automation platform then calls, is a short function.

Source: Data API: Working with webhooks. The comparison with timingSafeEqual is a standard Node practice and not part of the Webflow page. The full receiver is built on Webhooks.

If the call to the platform is made directly from Webflow, nothing can be verified and the secrecy of the URL is the only protection. For the garden, a harmless Slack message is acceptable on a secret URL, whereas a step that changes a booking should sit behind the relay.