How to connect Kit (ConvertKit) to Google Sheets, consent included

A subscriber export is a list of people who agreed to hear from you, which makes it different from most exports on two counts. The agreement itself is data you need to keep, and the copy you have just made sits outside the system that manages unsubscribes.

Both of those matter more than the mechanics. An out-of-date subscriber list in a spreadsheet is the kind of thing that ends up mail-merged six months later, by somebody who did not know it was stale, to people who have since unsubscribed.

What we'll cover

• The export is a copy that does not update
• Consent is a column
• Building it with CodeWords
• Tags, sequences, and forms are different things
• What the export is actually for
• State that changes after you export
• What not to export
• The other direction, which is usually the better one
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

The export is a copy that does not update

Unsubscribes do not propagate. Somebody who opts out is suppressed in Kit and remains in your spreadsheet indefinitely.

Bounces and complaints likewise. An address that hard-bounced is still a row.

Erasure requests do not reach it. Somebody exercising a deletion right is removed from the platform and not from the sheet.

A stale list gets reused. This is the actual risk: a spreadsheet from March used for a mail merge in September, sent to people who have since left.

Date the sheet prominently, and apply a retention rule that somebody actually enforces, because an export nobody deletes accumulates indefinitely.

The honest framing: export for analysis, not as a mailing list. If somebody wants to send to these people, they should send from Kit, where the suppression is applied.

Consent is a column

When and how somebody subscribed is the record that matters if anybody ever asks, and it is available.

The form or source they came through tells you what they agreed to, which is not always the same thing across forms.

Subscriber state — active, cancelled, bounced, complained — is the single most important column and the one most often omitted from an export.

Keep the state alongside the address, so nobody can look at the sheet and see a list of addresses without seeing which are live.

Export the state even when filtering to active subscribers, since a column of "active" makes it obvious the sheet was filtered rather than complete.

Never export addresses without the state, which is the shape of export most likely to be misused later.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which subscribers, which fields, and which sheet.
3. Authorize the connection to Kit with an API key, plus access to the target spreadsheet.
4. Describe the exceptions: a subscriber who has unsubscribed since the last run, a tag that no longer exists, a custom field that is missing.
5. Run it against a small segment and check the state column before exporting anything larger.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Tags, sequences, and forms are different things

They get conflated constantly, and an export that treats them alike produces a confusing sheet.

Tags are labels applied for any reason — a purchase, an interest, a behaviour — and a subscriber can have many.

Sequences are automated series somebody is enrolled in, with a position and a completion state.

Forms are how somebody arrived, which is the closest thing to a consent record.

A subscriber's tags are many-to-one, so exporting them means either a joined cell, a column per tag, or one row per tag — and the last breaks counting.

A column per tag is usually most useful when the tag set is small and stable, because it makes filtering and counting straightforward.

Report the tag list separately if it is large, since a sheet with ninety tag columns is a sheet nobody can read.

What the export is actually for

Worth asking, because the answer changes what you build.

Analysis of growth and segments — subscribers by source, by month, by tag — which is a summary rather than a list of people.

Joining with your own data, such as which subscribers became customers, which needs the addresses and belongs somewhere more controlled than a spreadsheet.

A backup, which is reasonable and should be treated as sensitive rather than left in a shared drive.

Reporting to somebody who does not have Kit access, which almost always wants the summary rather than the list.

Sending email, which is the one answer that means the export is the wrong approach entirely.

If the purpose is analysis, export aggregates. Most requests for a subscriber list turn out to be requests for a number.

State that changes after you export

Subscribers unsubscribe continuously, so any list is decaying from the moment it is written.

Tags are added and removed by automations you may not know about.

Sequences progress, so a position captured today is wrong tomorrow.

Custom fields get updated by forms and integrations.

Re-export rather than update in place for anything you intend to rely on, and date every version.

Report the churn. How many subscribers unsubscribed since the last export is a more useful number than the total, and it is the one nobody has.

What not to export

Addresses without the state column, which is the export most likely to be misused.

Anything to a link-shared spreadsheet. A subscriber list on "anyone with the link" is a genuine exposure.

More custom fields than the question needs, since these often contain personal detail collected for one purpose.

A full list when a count would do, which is most of the time.

Anything you would be uncomfortable seeing forwarded, because a spreadsheet gets forwarded.

The other direction, which is usually the better one

Most requests to export subscribers turn out to be requests to combine them with something else, and pushing in beats pulling out.

Send purchase and usage data into Kit as custom fields, so segmentation happens where the sending happens.

Tag from your own systems — became a customer, churned, attended the webinar — so a segment is one click rather than a spreadsheet join.

Update rather than create. Matching on email address and updating avoids the duplicate subscribers that manual imports produce.

Respect the state. Adding someone back who unsubscribed is the worst possible outcome of an import, and an automation should explicitly refuse rather than silently re-subscribe.

Keep the field vocabulary small, since custom fields accumulate and a subscriber record with forty fields is one nobody can segment on.

Nothing leaves the platform this way, which sidesteps the entire copy problem — the data goes in, the sending stays where the suppression is applied.

Making it survive

Export incrementally where the list is large, using the last-updated cursor, and reconcile with a periodic full export to catch removals.

Always include the state column, and date the sheet visibly.

Replace a named range rather than appending, so unsubscribes are reflected rather than accumulating.

Handle pagination, since subscriber listings page and a partial export looks complete.

Report the outcome. Subscribers exported, by state, and the change since the last run.

Limits worth knowing about

Rate limits apply, so a large list export needs pagination and pacing.

Sheets has a cell limit, which a large list with many tag columns reaches sooner than expected.

Tag and field identifiers are stable; names are not, so match on identifiers where you can.

Deleted subscribers do not appear, so an incremental export keeps rows for people who have been removed unless something reconciles.

The platform is now called Kit, with ConvertKit as the former name, so documentation and tooling circulate under both.

What to set up first

A weekly summary rather than a list: subscribers by state, new subscribers by source, and unsubscribes since last week. It answers what people actually ask, it contains no personal data, and it can be shared without anybody thinking about who can see the sheet.

Two habits make the difference. Report the churn alongside the total, since the growth number without it is the half of the story everybody quotes. And start with the summary rather than the list, because most requests for "the subscriber list" are satisfied by a number and the list is the version that creates a lasting obligation.

Frequently asked questions

Is a subscriber export a privacy problem?

It creates a copy outside the platform's suppression and deletion, so unsubscribes and erasure requests will not reach it. That is manageable with dating, retention, and controlled sharing — and avoidable entirely if a summary answers the question.

Should I export the list or a summary?

A summary, unless something specifically needs individual addresses. Most requests for a list are requests for a number, and the summary carries no ongoing obligation.

Which column is most often missing?

Subscriber state. An export of addresses without it is the shape most likely to be misused later, because nothing in the sheet indicates which of those people have since unsubscribed.

How should tags be exported?

A column per tag when the tag set is small and stable, since it makes filtering and counting straightforward. A joined cell when there are many. One row per tag breaks counting, so avoid it unless the sheet is specifically about tags.

Why does the export still contain people who unsubscribed?

Because the copy does not update, and an incremental export cannot see removals. Replace rather than append, and reconcile against a periodic full export.

Is it safe to mail-merge from the sheet?

No. Send from Kit, where suppression is applied. A spreadsheet has no idea who has unsubscribed since it was written, and that gap is exactly where the problem occurs.

Is it ConvertKit or Kit?

Kit — the platform was renamed, and ConvertKit remains in circulation in older documentation and tooling. Check which naming your credentials and libraries expect.

Is there an alternative to exporting subscribers?

Usually a better one: push your own data into Kit as tags and custom fields, so segmentation happens where the sending happens. Nothing leaves the platform, which avoids the stale-copy problem entirely.

What should an import never do?

Re-subscribe somebody who opted out. Match on email, update rather than create, and refuse explicitly when the subscriber's state says they have unsubscribed — silently adding them back is the worst outcome an import can produce.

What is the most useful weekly number?

Unsubscribes alongside new subscribers. Growth reported on its own is the half of the story everybody quotes, and the churn figure is what tells you whether the content is working or the list is simply being topped up faster than it leaks.

Should the sheet hold custom fields?

Only the ones the question needs. Custom fields often hold personal detail collected for one specific purpose, and exporting all of them moves that detail somewhere with different sharing and no retention rule.

Related reading

• ConvertKit and CodeWords
• Connecting SendGrid to Google Sheets
• CodeWords integrations and templates