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

To connect Kit (formerly ConvertKit) to Google Sheets, export each subscriber with a state column (active, cancelled, bounced or complained), the date and source of consent, and a visible export date. Treat the sheet as a copy for analysis, and send email only from Kit, where unsubscribes are applied.

A subscriber export differs from most exports on two counts. The consent record is data you must keep, and the copy sits outside the system that manages unsubscribes. A stale list in a spreadsheet gets mail-merged months later by someone 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 of the export
• What to set up first
• Frequently asked questions

Key takeaways

• Export the subscriber state next to every address, because an address without its state is the export most likely to be misused.
• Treat the sheet as a dated copy for analysis, because unsubscribes, bounces and erasure requests never reach it.
• Export a summary instead of a list whenever a number answers the question.
• Send email only from Kit, where suppression is applied, and never mail-merge from the sheet.
• Push your own data into Kit as tags and custom fields instead of pulling subscribers out.

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 do not propagate either. An address that hard-bounced is still a row.

Erasure requests do not reach the sheet. A person who exercises a deletion right is removed from the platform and stays in the sheet.

A stale list gets reused. This is the main 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 enforces, because an export nobody deletes stays forever.

Export for analysis, not as a mailing list. Anyone who wants to email these people should send from Kit, where suppression is applied.

Consent is a column

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

The form or source they came through tells you what they agreed to, which differs between forms.

Subscriber state (active, cancelled, bounced or complained) is the 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, because a column of "active" shows the sheet was filtered and not complete.

Never export addresses without the state. That export is the one most likely to be misused later.

Building it with CodeWords

CodeWords connects to 3,000+ integrations, and each 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. Pro costs $39 per month ($33 per month billed yearly) and Business costs $100 per month (CodeWords pricing page, 2026); details are on the pricing page.

Tags, sequences, and forms are different things

Teams often confuse the three, 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 can have many tags, so exporting them means a joined cell, a column per tag, or one row per tag. One row per tag breaks counting.

A column per tag works best 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

Ask first what the export is for, because the answer changes what you build.

Analysis of growth and segments, such as subscribers by source, by month or by tag. This needs a summary, not a list of people.

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

A backup, which is reasonable. Treat it as sensitive and keep it out of a shared drive.

Reporting to somebody without Kit access, who almost always wants the summary and not the list.

Sending email, which is the one purpose where an export is the wrong approach.

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 out of date 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

Pushing your data into Kit is usually better than pulling subscribers out, because most export requests are really requests to combine subscribers with other data.

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

Tag from your own systems when a person becomes a customer, churns or attends a webinar, so a segment is one click and not a spreadsheet join.

Update, do not create. Matching on email address and updating avoids the duplicate subscribers that manual imports produce.

Respect the state. Adding back someone who unsubscribed is the worst outcome of an import, so the automation should refuse explicitly instead of silently re-subscribing.

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 removes the copy problem: the data goes in, and the sending stays where 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 instead of appending, so unsubscribes are reflected and rows do not pile up.

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 of the export

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

Google 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, and ConvertKit is the former name, so documentation and tooling use both.

What to set up first

Set up a weekly summary instead of a list: subscribers by state, new subscribers by source, and unsubscribes since last week. The summary answers what people ask, contains no personal data, and can be shared without anyone worrying about who can see the sheet.

Two habits make the difference. Report the churn alongside the total, because growth without churn is half the story. And start with the summary instead of the list, because a number satisfies most requests for "the subscriber list" and the list creates a lasting obligation.

Frequently asked questions

Is a subscriber export a privacy problem?

It can be. The export creates a copy outside the platform's suppression and deletion, so unsubscribes and erasure requests never reach it. Dating the sheet, setting a retention rule and controlling who can open it manage the risk, and a summary avoids it entirely.

Should I export the list or a summary?

Export a summary unless something specifically needs individual addresses. Most requests for a list are really requests for a number, such as subscribers by state or by source, and a summary carries no personal data and no ongoing obligation to keep it current.

Which column is most often missing?

Subscriber state is the most often missing column. An export of addresses without it is the most likely to be misused later, because nothing in the sheet shows which of those people have since unsubscribed, bounced or complained. Add it first.

How should tags be exported?

Use a column per tag when the tag set is small and stable, because it makes filtering and counting straightforward. Use a joined cell when there are many tags. Avoid one row per tag unless the sheet is about tags, because it breaks subscriber counts.

Why does the export still contain people who unsubscribed?

The copy does not update, and an incremental export cannot see removals. Replace the named range on each run instead of appending, and reconcile against a periodic full export so that unsubscribed and deleted subscribers disappear from the sheet over time.

Is it safe to mail-merge from the sheet?

No. Send from Kit, where suppression is applied. A spreadsheet has no record of who unsubscribed after it was written, and that gap is where mail sent to people who opted out comes from. Use the sheet only for analysis.

Is it ConvertKit or Kit?

The platform is now called Kit, and ConvertKit is the former name. Older documentation and tooling still use ConvertKit, so check which name your credentials and libraries expect before you build, and use the current name in anything customers see.

Is there an alternative to exporting subscribers?

Yes, and it is usually better: 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 and keeps unsubscribe handling in one place.

What should an import never do?

An import must never re-subscribe someone who opted out. Match on email address, update instead of creating, and refuse explicitly when the subscriber's state says they unsubscribed. Silently adding them back is the worst outcome an import can produce. Test this rule before the first live run.

What is the most useful weekly number?

Report unsubscribes alongside new subscribers. Growth reported alone is half the story. The churn figure shows whether your content is working or whether the list is only being topped up faster than it loses people, and few teams track it.

Should the sheet hold custom fields?

Hold only the custom fields the question needs. Custom fields often contain personal detail collected for one purpose, and exporting all of them moves that detail to a place with different sharing rules and no retention rule. Fewer columns also make the sheet easier to read.

Related reading

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