Webflow Optimize API: What Can Revenue Teams Now Report?

Can you finally pull Webflow Optimize test results into your revenue reports?

Yes. Webflow now has an Optimize API that reads your optimizations and their results through the Data API. That means the variation numbers you used to screenshot from the Optimize dashboard can flow into a spreadsheet, a warehouse, or a CRM report. The real question is which numbers deserve a place next to pipeline.

For most of the B2B teams I work with, website tests have lived in their own little world. Someone runs a headline test on the demo page, watches the dashboard for a few weeks, picks a winner, and moves on. Sales never sees it. The board deck never mentions it. The test result and the revenue result never meet.

An API changes that, but only if you decide up front what you want it to answer. In this piece I will walk through what Webflow actually shipped, what the data can and cannot tell you, and how I would wire it into a go-to-market reporting stack without fooling yourself.

What did Webflow actually release?

Webflow's developer changelog first listed the Optimize API as a beta on September 30, 2026, then published a second entry on October 15, 2026 titled "New: Optimize API" without the beta label. It offers eight read-only endpoints that work with Webflow sites on the Optimize add-on and with non-Webflow sites that use Optimize.

According to Webflow's "Working with Optimize" documentation, the eight endpoints cover listing the Optimize IDs your token can access, listing optimizations with their type, status, and intervals, getting per-variation results for one goal, splitting those results by the segments of one dimension, viewing results by day or week, listing an interval's goals, listing the dimensions you can group or filter by, and listing the values seen for a dimension.

The docs say every one of these endpoints is a read-only GET request. You cannot create or stop a test through this API. It is a reporting surface, and I think that is the right first move. Reading results is where most teams are stuck today.

Access is simple to describe. The docs state that Optimize endpoints require an access token with the sites:read scope and a site with the Optimize add-on. Webflow sites accept OAuth app tokens and Site API tokens, while non-Webflow sites accept only OAuth app tokens.

What numbers does the Optimize API return for each variation?

For each variation and one goal, the results endpoint returns sessions, users, conversions, and conversion rate. Tests also carry lift, statistical significance, and a winner flag. Value goals add total value and value per conversion. AI-optimized runs use a strength score instead, and personalization has no winner at all.

Webflow's docs define a session as a period of continuous activity that ends after 30 minutes of inactivity, and users as the unique visitors who saw the variation. Conversion rate is conversions divided by sessions, returned as a fraction, and lift is a fraction too. That detail matters the moment you paste these numbers into a sheet that formats everything as a percentage.

The split by optimization type is the part I want revenue teams to understand before they build a dashboard. A classic test gives you isWinner, lift, and statisticalSignificance. An AI-optimized run gives you strength. A personalization gives you no comparison fields, because, as the docs put it, it has no winner. If you build one chart that treats all three the same way, it will lie to you.

Why should a GTM team care about A/B test data at all?

Because the website is part of the sales motion, not a side project. If a pricing page test raises demo requests but the extra demos never turn into opportunities, you have made your SDRs busier and your pipeline no better. Test data only becomes useful when it sits next to what happened after the click.

I build websites and the automations behind them for lead generation, and the gap I see most often is not a lack of tests. It is a lack of follow-through. Marketing reports a winning variation. Sales reports a flat quarter. Nobody connects the two, so nobody learns whether the winning page attracted the right buyer.

This is the same reason I pushed teams to pull AI visibility data into their reporting when Webflow opened that up. I wrote about that in my piece on what GTM teams should report from the Webflow AEO analytics API. The pattern is identical: a metric that lives only in a vendor dashboard rarely changes a decision.

Which Optimize metrics belong in a revenue report and which do not?

Put conversions, conversion rate, and the winner flag for your target goal into the revenue report, and pair each with downstream pipeline from the same period. Leave sessions, raw users, and AI strength scores in the marketing layer. Executives need to see whether a change moved qualified pipeline, not how many people saw a headline.

My rule is that a website metric earns a place in a revenue report only when someone in sales could act on it. A demo form conversion rate passes that test. A scroll metric on a blog post does not. Sessions are useful context for the marketer running the test, but they are noise in a pipeline review.

I am also cautious with the strength score from AI-optimized runs. It describes how the system is allocating traffic, which is helpful for the person managing the run, but it is not the same thing as a test that reached significance. I would label it clearly or keep it out of executive views entirely.

The value fields are the exception worth exploring. If your goal carries a value, the docs say results include total value and average value per conversion. For a team that assigns a rough dollar value to a demo request or a trial start, that gets you closer to a revenue conversation without pretending a test closed a deal.

How would I wire the Optimize API into a reporting stack?

Start small. Pull the list of optimizations and the results for your target goal once a day into a spreadsheet or Airtable base, keyed by optimization ID and date. Then join that table to CRM records by landing page and date range. Only automate further once a human has read a month of joined data.

The docs suggest beginning with the endpoints that list Optimize IDs and optimizations, since they return the IDs every other call needs. That matches how I would build it. A scheduled job in n8n, Make, or Zapier calls those first, stores the IDs, then requests results for each live optimization and writes one row per variation per day.

The join is where the value lives. In HubSpot, I would record the first conversion page on the contact and the date of that conversion. That lets you match contacts who converted on the tested page during the test window to the variation results for the same window. It is not perfect attribution, but it is honest and repeatable. If you want a broader view of how I think about this for small teams, my piece on marketing attribution for a small B2B team goes further.

I would resist the urge to push variation IDs onto every contact record on day one. It sounds powerful. In practice it creates a field nobody maintains, and six months later nobody remembers which test a value referred to.

What limits should you design around before you build?

Three limits shape the build. Each access token can have only one Optimize request in flight at a time, history cannot start earlier than 18 months ago, and a date range that crosses from one interval into the next is rejected. Design your job to run sequentially and to respect interval boundaries.

The concurrency rule is the one that will catch people. Webflow's docs say each access token can have one Optimize request in flight at a time, across all Optimize endpoints, and that exceeded limits return a 429 response with a Retry-After header. A workflow that fans out parallel requests for every optimization will fail. Run calls one after another and honor the retry header.

Freshness matters too. The docs say initial processing takes about 30 minutes before data appears, and results then update every minute. For a daily revenue report that is more than enough. For a real-time Slack alert, I would wait until the 30-minute window has passed before trusting the first numbers.

A few smaller rules are worth knowing. Timestamps with offsets or date-only values are not accepted, groupBy works with any dimension except urlParameter, and a filter can name at most 20 dimensions. None of these are dealbreakers. They are the kind of thing that costs an afternoon if you discover them in production instead of in the docs.

Is this worth building if you only run a few tests a year?

Probably not as an automated pipeline. If you run two or three tests a year, a manual export after each test, pasted next to the pipeline numbers for the same window, gives you most of the learning. The API earns its keep when tests run continuously or when several people need the same numbers.

I say this as someone who likes automation. I have automations in production for clients like Ajust, where Airtable and WhaleSync move real work for real people. Those earn their maintenance cost because the volume is high. A reporting job for a test that runs twice a year does not have that volume.

The honest middle ground is a template. Build the join once in a spreadsheet, document the steps, and run it by hand at the end of each test. If you find yourself doing it monthly, that is your signal to automate. If you have never run a test at all, start with my guide to running your first Webflow Optimize test before you worry about the API.

What should you do next?

Pick one live or recent optimization tied to a revenue page, such as pricing or demo. Pull its results for the target goal, put them next to the opportunities created from that page in the same window, and read them together with sales. If that conversation changes a decision, automate it. If not, keep it manual.

The release itself is small and practical. It does not add new testing powers. What it does is remove the excuse that website experiments cannot be reported alongside pipeline. For GTM teams that already run tests, that is a meaningful shift in how the website gets judged.

If you want help connecting Optimize results to your CRM, or deciding whether your testing volume justifies the build at all, reach out. I am happy to look at your setup and tell you honestly whether it is worth doing.