Wrike

Webflow forms collect project requests, but nothing in Webflow assigns that work or tracks it through production. Approval routing needs a second system as well. Marketing and agency teams end up pasting submissions into email threads and spreadsheets by hand, and site updates stall behind requests sitting unread in an inbox.

Wrike closes that gap. A submission on your site becomes a Wrike task with mapped fields, so answers land in the task title and description as well as in custom fields, rather than arriving as one free-text blob. Status changes in Wrike can flow back to CMS items, and because both products now run MCP servers, an AI tool you already use can read and write across the pair without any glue code.

The pairing suits marketing operations teams running a website request queue, and agencies that keep client intake and approval work in one Wrike view. Content teams also use it to open follow-on production tasks whenever an editor adds a CMS item.

How to integrate Wrike with Webflow

What is Wrike? Wrike is enterprise work management software covering task and project tracking, custom request forms, proofing and approvals, dashboards, and time tracking. Its REST API is open on every plan, from Free upward, and so is its MCP server.

Teams pair the two when website work starts on the site itself, either as a request form or as a new CMS item that needs an owner. Agencies building Webflow sites for clients keep intake, production and sign-off in one Wrike queue. Marketing teams move site-change requests out of email and into a tracked backlog. Because the Webflow App Marketplace has no Wrike app and Wrike's integrations directory has no Webflow entry, every working setup runs through MCP, an embedded form, an automation platform, or the two REST APIs.

Setup effort and the amount of control you get differ sharply across those four routes:

• MCP servers: Wrike and Webflow each expose one, so an AI tool can read a task queue and update CMS items in the same conversation, with no code to host.
• Embedded request forms: Wrike generates iframe HTML for an external request form that you paste into a Code Embed element on any Webflow page.
• Automation platforms: Zapier, Make, and IFTTT wire Webflow triggers to Wrike actions in a visual builder, again with no server of your own.
• The two REST APIs: Writing your own webhook handler buys real-time two-way sync and full control over field mapping, at the cost of server-side development.

Most teams end up combining two of them: a form or an automation for unattended intake, then an agent or a custom function for anything the no-code path cannot express.

Connect both MCP servers to your AI tool

Both companies ship an MCP server, so the quickest route to a working Wrike and Webflow connection now involves neither code nor an automation platform. Point your AI tool at the Webflow MCP server and the Wrike MCP server in one session, and it can read a Wrike queue and patch the matching Webflow CMS items directly.

Wrike's server connects over OAuth with one-click sign-in from Claude, ChatGPT, Microsoft Copilot, Cursor, and other MCP clients, and it is available on every Wrike plan including Free. It runs stateless and passes calls straight through to the Wrike API, which means it inherits your existing roles and sharing rules: an agent sees exactly what the signed-in user sees, every action lands in the Wrike activity stream under that user, and deletes are not exposed at all.

On our side, the server covers design and build work, content management, traffic analysis, multi-step automation, and governance controls including per-site agent instructions and the site activity log. A few capabilities do depend on having Webflow open with the Bridge App connected, and each authorization reaches a single workspace.

We would push back on treating this as a replacement for the sections below. An agent connection is excellent for supervised work: drafting CMS entries from a week of completed Wrike tasks, or opening tasks for every page a content audit flags. It does not run in the background. Nothing fires on its own when somebody submits a form at 2am, so unattended intake still belongs in a form embed, an automation, or your own webhook handler.

Embed a Wrike request form

Wrike's external request forms generate iframe HTML that you paste into a Code Embed element, which makes this the fastest way to collect structured work requests on a Webflow page without writing anything. Each submission opens a Wrike task or project automatically, and paid accounts can take up to 500 submissions per 10 minutes through one form.

External forms need a Wrike Business, Pinnacle, or Apex plan, and trials cannot use them unless Wrike Support switches them on. On the Webflow side, a Code Embed element needs a paid Site plan or a paid Workspace plan.

To set it up:

1. In Wrike, open Settings > Account management > Request forms and click + Form to build the form.
2. In the left panel, tick Enable public link, then click Publish for a new form or Save for an existing one.
3. Back on the request forms page, click the Share publicly icon beside the form and open the HTML code tab.
4. Set the width and height in pixels, then copy the code.
5. In Webflow, add a Code Embed element to the canvas and paste the iframe.
6. Save the embed and publish the site. Custom code renders in preview but only goes live once you publish, and the same applies to head and body tags.

Embedded forms carry mapped responses, so a given answer can populate the task title, its description, its start and end dates, or a custom field. You can also require a respondent name and email, add a CAPTCHA, and send a confirmation email once the form is in. The Design tab handles branding: logo size and alignment, a solid colour or image background, and a light or dark theme, with the Wrike logo removable on Pinnacle and Apex only.

Two things catch people out. Wrike issues a fresh public link whenever you disable and re-enable it, or unpublish and republish the form, which silently breaks the embed you already pasted, so collect the replacement from the sharing controls and republish. Externally submitted items also list Wrike Bot as the author rather than the person who filled the form in, so route and report on a form field rather than on the creator.

Connect through Zapier, Make, or IFTTT

When a submission has to reach Wrike unattended and you would rather not host anything, an automation platform sits between the two. Zapier is the one Wrike documents itself and it works on every Wrike plan, which makes it the shortest route from a Webflow form to a Wrike task; the Webflow and Wrike connectors list what is wired up on each side. Make has a Webflow App Marketplace listing and native modules for collections, items, products, orders, pages, and asset folders, though no prebuilt Webflow to Wrike scenario ships with it.

The pairings people reach for most often look like this:

• Form submission to task: Webflow's new form submission trigger pairs with Wrike's create task action, and this is the intake pattern nearly every team starts with.
• Order to task: A new or updated Webflow ecommerce order can open a Wrike task, log a time entry, or post a comment on work that already exists.
• Task or folder to CMS item: Wrike's new task and new folder triggers feed Webflow's create and update item actions, so project records can surface on the site itself.
• Comment events: Webflow's comment and resolved comment thread triggers let editorial feedback left on a page open or close the matching Wrike work.
• Prebuilt flows: viaSocket ships ready-made Webflow and Wrike flows, including one that creates a Webflow item when a new folder appears in Wrike.

IFTTT connects the same pair through custom applets only and ships none prebuilt. Test the timing before you promise anyone real-time behaviour, because some Wrike triggers poll on a schedule rather than firing on the event, so a task created at the top of the hour may not reach Webflow for several minutes.

Build with the Webflow and Wrike APIs

The APIs are the only path to real-time, two-way sync between Wrike work items and Webflow content, and they are the only path that asks for a developer. You write a server-side function, hosted on Vercel, Netlify, or Cloudflare Workers, that receives webhooks from one platform and calls the other's REST API.

Wrike's API is at version 4. Authentication runs on OAuth 2.0 or a permanent token issued from the App Console, and the difference matters: OAuth access tokens last one hour, and each refresh invalidates the previous refresh token, so build that rotation in from the start. The token response also carries a host field, because Wrike keeps account data in United States and European Union data centres. Every call must go to https://<host>/api/v4, and the wrong base URL returns a 401 not_authorized even when the token is perfectly valid.

Across both platforms, the pieces you will be calling break down like this:

• Wrike work items: The Wrike API covers tasks, folders, comments, attachments, and approvals under that version 4 base URL.
• Wrike events: Wrike webhooks register at account, folder, or space level and confirm ownership through a signed handshake before any event is delivered.
• Webflow content: The Webflow API creates and patches Webflow CMS items and reads stored form submissions.
• Webflow events: Webflow webhooks push form submissions and CMS item changes to your endpoint, signed so you can reject anything you did not trigger.

Creating Webflow webhooks through the API takes a bearer token from a Data Client App carrying the sites:write scope, so register an app before you script any of this.

Create Wrike tasks from Webflow form submissions

This is the intake pattern again, in code, and it is the piece worth building yourself if your field mapping is complicated. A form_submission webhook fires on every submission and delivers a timestamp alongside the form name and field data to your function, which then creates the Wrike task.

To implement it:

1. Register the webhook by sending triggerType: "form_submission" and your endpoint URL to POST https://api.webflow.com/v2/sites/{site_id}/webhooks. An optional filter narrows delivery to one named form.
2. Compute an HMAC-SHA256 of timestamp + ":" + JSON.stringify(request_body) using your client secret, then compare the result against the x-webflow-signature header before you act on anything.
3. Call POST https://<host>/api/v4/folders/{folderId}/tasks with the required title parameter, mapping payload.name to the title and the payload.data key-value pairs to the description or to customFields.
4. Store the Webflow formId against the returned Wrike taskId so a later sync can match the two records without guessing.

Keep both tokens on the server. Wrike and Webflow credentials in browser code are readable by anyone who opens the network tab.

Sync Wrike status changes back to the CMS

Running the sync in the other direction is what puts real project status on a client-facing page. Wrike fires webhooks for task, folder, project, comment, timelog, and approval events, among them TaskStatusChanged, TaskCustomFieldChanged, and TaskApprovalStatusChanged. Point those at a function that patches CMS items and your site can render live status in a Collection List.

To implement it:

1. Register a webhook by sending hookUrl and events: ["TaskStatusChanged"] to POST /webhooks, or to the folder-scoped /folders/{folderId}/webhooks, adding a secret so signatures can be verified.
2. On each event, map the payload's status and customStatusId onto a status field on the matching CMS item.
3. Call PATCH https://api.webflow.com/v2/collections/{collection_id}/items/live with the cms:write scope to update and publish in one step, or use the staged endpoint followed by a publish call.

Wrike does not guarantee exactly-once delivery, so key off the Idempotency-Key header and treat a repeat as a no-op. Register these webhooks under a dedicated service account, because Wrike permanently deletes every webhook a user created the moment that user leaves the account. One more trap: Wrike automation rules deliberately do not run for items created or modified through the API, so any branching logic you were expecting Wrike to handle has to live in your function instead.

What you can build with the Wrike Webflow integration

Putting Wrike behind Webflow lets you run request intake, production tracking, and publishing approvals in one system, with nobody copying form data between tools by hand. The four patterns below cover most of what teams actually ship.

• Client intake portals: An agency embeds a Wrike request form on its Webflow services page so every enquiry arrives as a routed task with mapped fields. Ogilvy Australia ran that pattern across a BMW dealer network of more than 700 offices, sending creative briefs straight into production.
• Content production pipelines: A collection_item_created webhook fires when an editor adds a blog post, and your function opens the Wrike tasks that post needs before it can go live, from image sourcing through to SEO review.
• Approval-gated publishing: A completed Wrike approval triggers a CMS item or full site publish through the API, and Wrike's HTML proofing lets reviewers mark up the live page and compare snapshots before they sign anything off.
• Status pages that stay honest: A Wrike status change patches the CMS item behind a client-facing project page, so the site reflects real progress rather than whatever somebody last remembered to type into it.

The intake half is worth getting right before you build anything custom, so see how we route form submissions from Webflow through Zapier into another system, then swap the destination for Wrike. Once that is running, connect the MCP server and let your AI tool handle the reporting and cleanup work on top.