How Do You Get a Whole Webflow CMS Collection Into a Spreadsheet?

How do you get a whole Webflow CMS collection into a spreadsheet?

Page through the list endpoint a hundred items at a time, keep only the fields you will actually sort by, and write the result to a sheet. That is the whole job. The parts that trip people up are pagination, the rate limit, and the temptation to bring the article body along for the ride.

I am writing this for one specific situation. You have a Webflow collection with more items than you can eyeball, you need to answer a question about the whole library rather than one item, and you do not want to build a permanent sync to do it.

This is a reporting pull, not an integration. Knowing that up front saves you from building something far more complicated than the question deserves.

Step one: what are you actually trying to find?

Decide the question before you write a line of code, because the question determines which fields you need and nothing else does. Which posts have no category. Which have not been updated in a year. Which have slugs that collide. Which are missing an excerpt.

Every one of those is answerable from four or five fields. None of them requires the article body. I have watched people pull an entire content library including rich text, crash a sheet, and conclude the approach does not work, when the actual problem was that they never decided what they were looking for.

Write the question at the top of the sheet as a literal sentence. It sounds like a formality and it is the thing that keeps the pull small.

Step two: how does pagination work on the list endpoint?

With limit and offset, and the limit is capped. Webflow's API reference describes limit as the maximum number of records to be returned with a maximum of 100, and offset as the offset used for pagination if the results have more than limit records.

So the loop is simple. Request with a limit of 100 and an offset of 0, then 100, then 200, and keep going until you have everything. You do not have to guess when to stop, because Webflow's response includes a pagination object containing limit, offset, and total, where total is the total number of items in the collection.

Use that total. Read it on the first response, calculate how many requests you need, and let the loop terminate on a known number rather than on an empty response. A loop that stops when it sees nothing is a loop that runs forever the day something returns an unexpected shape.

Step three: what should you pull, and what should you leave behind?

Keep the identifiers, the dates, and the small fields. Drop anything long. In practice that means the item id, the slug, the name, whatever reference fields you care about, and the timestamps, and it means deliberately discarding rich text before it ever reaches the sheet.

The API will hand you the full field data whether you want it or not, so the discarding happens in your code rather than in the request. Build the row you want explicitly, field by field, rather than dumping the object. That also means a new field added to the collection later does not silently change your sheet's shape.

You can narrow the work further at the source. Webflow's reference documents a filter parameter that lets you filter collection items by custom field values using bracket notation, plus top level filters for name, slug, createdOn, lastPublished and lastUpdated. If your question only concerns items changed this year, filter server side and fetch less.

Step four: how do you avoid hitting the rate limit?

Know your ceiling and stay under it deliberately. Webflow's documentation gives the Data API limits as 60 requests per minute on Starter and Basic, 120 on CMS, eCommerce and Business, and custom on Enterprise. Exceed that and the API returns HTTP 429 Too Many Requests.

Do the arithmetic before you run anything. A collection of a thousand items at 100 per request is ten calls, which is comfortably inside any of those ceilings. A collection of fifty thousand is five hundred calls, and now the plan you are on determines whether this takes five minutes or nine.

Handle the 429 properly rather than hoping. Webflow says the response includes a Retry-After header telling you how long to wait, typically 60 seconds, and notes that its SDK includes built in exponential backoff. If you are using the SDK you inherit that. If you are calling the API directly from a script or a workflow tool, respecting Retry-After is your job, and it is three lines that save you a corrupted half finished export.

Step five: what does the sheet need besides the fields?

Three things the API will not give you. A pull timestamp, so nobody argues about whether the sheet is current. A row count you can compare against the total the API reported, so a truncated pull is obvious. And your derived columns.

The derived columns are where the value actually is. Days since last updated, computed from the timestamp. A flag for missing excerpt. A flag for missing category. Slug length. Those are the columns you will sort by, and none of them exist in the source data.

Put the raw fields on one tab and the analysis on another. When you re run the pull you overwrite the raw tab and your formulas survive, which turns a one off export into something you can repeat in a minute.

How do you keep it current without building a sync?

Re run it on a cadence that matches the decision, not the data. For a content audit that is monthly or quarterly. A permanent two way sync is a large, ongoing commitment, and the failure modes are real, as I covered in the failure modes of syncing Airtable and Webflow CMS.

If you do schedule it, schedule the whole pull rather than an incremental one, at least while the collection is small enough to allow it. Incremental sync logic is where the bugs live, and a full replace of a few thousand rows is cheap and always correct.

Whatever you choose, make the job loud when it fails. A scheduled export that silently produces a partial sheet is worse than no export, because somebody will make a decision on it. That is the same argument I make about monitoring silent automation failures, and it applies to a humble reporting script exactly as much as to a production pipeline.

What does this let you answer that you could not before?

Anything about the shape of the library rather than the content of one item. After more than 350 published articles, the questions I find most useful are all structural. How many posts have no inbound internal link. How many share three or more words in their slug with another post. How many have not been touched since publication.

None of those is answerable by browsing the CMS, and all of them are trivial once the collection is a table. That is the real reason to do this, and it is worth doing even if you never automate it.

It also pairs well with data you already export from elsewhere. Once the CMS is tabular you can join it against performance data by slug, which is when the audit stops being a tidying exercise and starts driving decisions. If you already run a CSV export workflow for client reporting, this is the other half of that join.

What should you do next?

Pick your largest collection, write one question at the top of a blank sheet, and pull only the fields that question needs. Read total from the first response, loop on offset, and stop when you have everything. If it works, you have an audit. If it fails, it will fail on pagination or on the rate limit, and you now know what both look like.

Then add the two columns that matter most to you and sort by them. The first time you sort a content library by days since last updated is usually the moment a vague worry becomes a concrete list.

If you have a collection large enough that this is genuinely awkward, or a question you cannot work out how to express in fields, reach out. Framing the question is usually the hard part, and the pull is usually twenty minutes.