Customer.io consent records: the opt-in proof a regulator actually asks for
On 7 October 1970 the German state of Hesse adopted its Datenschutzgesetz, after the state parliament voted on it on 30 September 1970. Gloria González Fuster's history of data protection calls it the first data protection law ever adopted. Its defining feature, according to German Wikipedia, was an independent data protection commissioner whose job was to check. The 1977 federal act took it as its model.
The first law was thin. It let public bodies process personal data without the consent of the people concerned. Its 1978 replacement made processing depend on a legal basis or on the person's consent. This is the shape of the rule we still live with: someone can come and check, and you need a record to show them.
From 1970 to 2026 is 56 years by our arithmetic, and the question has not changed. When a complaint lands, the regulator does not ask whether a person is subscribed. It asks you to show how they came to be.
TL;DR: Customer.io shipped consent records on 1 October 2026. They are a history of the opt-ins and opt-outs that reach Customer.io, with the topic or channel, the collection point and, for SMS, the reply text. An unsubscribe flag tells you where a person stands today. A consent record tells you when they got there and through which door. Neither tells you what they were told, because Customer.io stores no copy of your sign-up wording, and its own docs say it "does not verify consent". The ICO asks you to show who consented, when, what they were told, how, and whether they withdrew. Customer.io covers the when, the withdrawal and part of the how (the collection point). The wording and the form version are yours to keep. Turn consent records on now, close the gaps that bypass them, and archive what you can prove outside Customer.io. This is not legal advice: check your position with counsel.
What Customer.io consent records are
Customer.io announced the feature in its release notes on 1 October 2026. The announcement says every opt-in and opt-out; the docs list the exceptions, covered below. Accounts created on or after that date have records turned on already.
Older accounts are different, and the consent records docs are precise about it. Customer.io records consent for every account, but an administrator must turn records on in Workspace Settings > Consent before anyone can see them. That adds a Consent state panel to each profile, exports, segment conditions and starting records for choices made before recording began. The switch covers every workspace in the account, and only support can turn it off again.
The most important line in the docs is about what the feature is not. Consent records "don't decide who receives your messages". Customer.io still decides whether to send from a person's subscription preferences and sender opt-outs. Your channel subscription preferences are the gate; the consent record is the paper trail of who walked through it.
What the rules ask you to show
Start with the law. Article 7(1) of the UK GDPR reads:
"Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data."
The burden sits with you, not with the person who complained.
The ICO turns that into a checklist in its guidance on how to obtain, record and manage consent. You need "an effective audit trail of how and when consent was given". Its record has five parts:
- Who consented: a name or other identifier.
- When they consented: for online consent, a record with a timestamp.
- What they were told at the time: a master copy of the form and consent statement in use at that time, with version numbers and dates.
- How they consented: the data submitted, with a timestamp that links it to the version of the form.
- Whether they have withdrawn consent, and if so, when.
The ICO notes the guidance is under review after the Data (Use and Access) Act, so check the live page before you rely on any detail.
For marketing email to individuals in the UK, PECR applies on top. The ICO's PECR guidance on electronic mail marketing says unsolicited marketing to individual subscribers needs consent or every requirement of a soft opt-in. It adds that you should keep a record of the consent so that you can demonstrate it is valid.
The US is a different shape. For email, CAN-SPAM is an opt-out regime. The statute, 15 U.S.C. 7704(a)(4), makes it unlawful to keep sending commercial email more than 10 business days after an opt-out request. Penalties are set by reference to the FTC Act and adjusted for inflation in 16 CFR 1.98. The current figure there is $53,088 per violation, for penalties assessed after 17 January 2025. For a US email list, the record that matters most is the opt-out, and its date. SMS consent in the US sits under separate rules, which our post on A2P 10DLC registration covers from the carrier side.
None of this is legal advice. Whether your consent was valid in the first place is a question for counsel.
Where the record stops
Put the ICO's five parts next to what Customer.io stores and the gap is plain.
| ICO asks you to show | What a Customer.io consent record holds | What you keep yourself |
|---|---|---|
| Who consented | profile_identifier and its type, plus the person's ID in exports |
Nothing extra, if your identifiers are stable |
| When they consented | A timestamp for each record | The original date for anything before records began |
| What they were told | topic_name as it was at the time, and for SMS the sender number |
The form, consent wording and privacy notice, versioned and dated |
| How they consented | collection_point, plus response for SMS replies and delivery_id for unsubscribe links |
The page or flow the person used, if it ran outside Customer.io |
| Whether they withdrew | Each opted_out record, with its collection point |
Opt-outs taken by phone, post or support ticket, entered as changes |
Sources: Customer.io consent records docs; ICO consent guidance.
Read the third row twice. A topic name, stored as it was at the time, is not a consent statement. The record does not hold the sentence beside the tick box, the privacy notice version or the page it sat on.
Customer.io says so itself: "Customer.io does not verify consent, and recording an opt-in does not establish that valid consent was obtained." The docs add that you remain responsible for retaining any additional evidence needed to demonstrate consent.
Consent records answer the when and the where. Only you can answer the what.
Why an unsubscribe flag is not proof
Without consent records, a workspace carries consent as the unsubscribed attribute and, with the subscription centre on, cio_subscription_preferences. Both are a state. They tell you where a person stands now, which is exactly what sending needs and exactly what an audit does not.
With only the flag, you can say a person is subscribed. You cannot say when, through what, or on what wording. Anything can have set that value: an old CSV import, a CRM sync, or a team member fixing a profile by hand.
Two Customer.io defaults make it worse. People are subscribed to email and push by default, so a new profile looks opted in without ever opting in. And by default a new subscription topic has People are subscribed by default turned on, according to the subscription centre docs. Customer.io's own docs warn you to make sure you have your audience's consent before using that setting. A topic left at its default gets no starting record, because nobody chose anything.
So treat consent records as the history behind the flag, not a replacement for it. Our post on preserving unsubscribes on merge covers how the flag survives when two profiles merge. The record tells you why it was set.
The gaps that will catch you
Five paths change consent without leaving the history you would want, all from the docs.
No record of a first email opt-in
Without the subscription centre, unsubscribed is the only setting that decides email and push. A new profile is already subscribed, so nothing changes and nothing is recorded. The docs are blunt: Customer.io "doesn't record a person's first opt-in to email or push". If you need email opt-ins in the history, turn on the subscription centre and record each opt-in as a channel preference. Our guide to building a subscription centre covers the set-up.
Automations leave no trace
Changes an automation makes, like a Create or Update Person action, do not create records. That includes the docs' own double opt-in recipe, which stores the confirmation in a custom attribute set by an automation. The fix the docs give is to set the person's subscription preferences from your app when they confirm.
Identify calls can overwrite everything
Depending on the API and format, an identify call can replace all of a person's stored preferences instead of updating one. Customer.io then writes an api record for every preference whose value changes, even though the person chose none of them. Preferences the overwrite removes change status with no record at all. Send only the preferences that changed, following the examples for setting preferences outside the subscription centre.
Some consent is out of scope
Open-tracking consent does not create records, because it controls tracking, not whether a person receives messages. Push permission on a device does not either: the person grants it to your app, not to Customer.io.
The API forgets after 30 days
The App API returns consent records as activities, but those endpoints only guarantee the last 30 days. For a full history, export from Workspace Settings > Consent. Two quirks: the button says Export CSV but the file is JSON with one record per line, and a date range can be at most one year, or left empty for the full history.
Starting records are a snapshot, not a history
It is easy to assume consent records cannot be backfilled. They can, partly. When an older account turns records on, Customer.io writes a starting record for each choice a person has already made, read from current subscription preferences and sender opt-outs. For a large workspace this can take several days.
Read what that backfill contains. For a subscription preference, the timestamp is when the preference last changed, "the closest Customer.io can get" to the moment of choice. For a sender opt-out, Customer.io never stored when it happened, so the record is stamped with the time you turned records on. The docs sum it up: "A starting record shows that the choice exists, but not how the person made it."
What about loading old evidence in? CSV and SQL imports create records with the collection point import, but only when a value actually changes. An import records a change you made on the day you ran it, not the day the person agreed, and a person already subscribed gets no record at all. The docs describe no way to load historical consent with its original date and wording. Our rule for older lists: archive what you can prove, outside Customer.io, and do not invent the rest. If your sign-up database holds a timestamp and a form version for each person, keep that table unedited. It is your evidence for the years before 1 October 2026. Never fabricate opt-in events to make the history look complete: a tidy record you made up is worse than an honest gap.
How it fits the rest of your consent set-up
Consent records sit in the middle of a cluster of Customer.io features, and each touches the history differently.
| Feature | What it does | How it shows in consent records |
|---|---|---|
| Channel subscription preferences | Decides who receives a message by topic and channel | Each change is a record, unless an automation made it |
| Preserve unsubscribes on merge | Keeps the opt-out when two profiles become one | The flag survives; the history explains it |
| Delete vs suppress | Removes or blocks a profile | Records persist after deletion, attributed to the old cio_id |
| Forms | Captures sign-ups from your site | A form integration that changes subscriptions writes a form record |
| SMS keywords and carriers | STOP, START and carrier opt-outs | One record per reply or carrier report; replies include the text sent |
Deletion deserves a note. Customer.io keeps a deleted person's consent records but removes their consent state, and a returning profile with the same identifier starts with none. The ICO says you may need to keep a record of a withdrawal to maintain suppression lists. You do not need consent for that, provided you tell people you keep it, why, and on what lawful basis.
A set-up checklist
This is the order we would work in for a workspace created before 1 October 2026.
- Turn consent records on. Plan for several days of starting records on a large account.
- Archive your consent wording. Save every sign-up form, checkbox label and privacy notice with a version number and the dates it was live.
- Record the form version on the person. An attribute such as
consent_form_versionties each opt-in to the wording in your archive. This is our suggestion, not a Customer.io feature. - Turn on the subscription centre if you need email opt-ins in the history, and record each opt-in as a channel or topic preference.
- Move consent changes out of automations. Set preferences from your app or API instead, including double opt-in confirmations.
- Export on a schedule. The API only guarantees 30 days, so keep a regular export with your compliance files.
- Archive your pre-October 2026 evidence outside Customer.io. Do not import it as new consent records.
A consent audit like this is part of our email marketing consulting work.
When consent records will not help
- You send under the soft opt-in. The ICO allows marketing email without consent where you collected the address yourself during a sale or negotiations for one. You must market only similar products and offer an opt-out then and in every message since. Your evidence is that transaction and those opt-outs, not an opt-in record.
- You email corporate subscribers in the UK. The ICO says you can send electronic mail marketing to corporate subscribers without consent or a soft opt-in. Sole traders and ordinary partnerships count as individual subscribers, so the consent rules apply to them.
- You email only US recipients. CAN-SPAM needs a working opt-out and prompt honouring of it. Consent records still help, but for the opt-outs, not opt-ins.
- Your consent lives in another system. Customer.io only records what reaches it, so keep the audit in your CRM or consent tool.
We would still turn records on. The opt-out history alone answers the most common complaint: I unsubscribed and you kept emailing me.
Want help with yours? Send us an enquiry or book a call with David.
Frequently asked questions
What are Customer.io consent records?
Customer.io consent records are a history of the opt-ins and opt-outs that reach Customer.io, launched on 1 October 2026. Each record holds the action, the resulting state, the collection point and, where relevant, the topic, channel, sender or reply text (Customer.io docs).
Do consent records prove someone gave valid consent?
No, consent records show that a choice was recorded, not that the consent was valid. Customer.io says it does not verify consent. The record has no copy of the wording the person saw, so you keep that yourself (Customer.io docs).
How do I turn on consent records in Customer.io?
An account administrator turns them on in Workspace Settings > Consent by clicking Turn on… next to Record consent. The setting covers every workspace in the account and only support can turn it off again (Customer.io docs).
Can I import historical consent into Customer.io?
Customer.io writes starting records from each person's current preferences when an older account turns consent records on, but these show that a choice exists, not how it was made. The docs describe no way to load past consent with its original date and wording, so keep that evidence in your own archive (Customer.io docs).
Why is there no consent record for someone's email sign-up?
Customer.io does not record a first email opt-in when you use only the unsubscribed attribute, because new profiles are subscribed by default and nothing changes. Turn on the subscription centre and record each opt-in as a channel preference to capture it (Customer.io docs).
Do Customer.io automations create consent records?
No, changes an automation makes to a person's subscriptions, such as a Create or Update Person action, do not create consent records. Set preferences from your app or API instead if you want them in the history (Customer.io docs).
What does the ICO say I must record about consent?
The ICO says you must keep records showing who consented, when, what they were told at the time, how they consented, and whether they have withdrawn. Customer.io covers the when, the withdrawal and the collection point; the wording and the form version are yours to keep (ICO).
Sources
- Customer.io, Consent records, updated 8 October 2026.
- Customer.io, Release notes, entry of 1 October 2026, read 16 October 2026.
- Customer.io, Set preferences outside of the subscription centre, read 16 October 2026.
- Customer.io, Subscription centre, read 16 October 2026.
- legislation.gov.uk, UK GDPR Article 7: Conditions for consent, read 16 October 2026.
- ICO, How should we obtain, record and manage consent?, read 16 October 2026.
- ICO, How do we comply with the PECR electronic mail marketing rules?, read 16 October 2026.
- Legal Information Institute, 15 U.S. Code § 7704, read 16 October 2026.
- eCFR, 16 CFR 1.98: Adjustment of civil monetary penalty amounts, read 16 October 2026.
- Gloria González Fuster, History of data protection: 1970, read 16 October 2026.
- Wikipedia (German), Hessisches Datenschutzgesetz, read 16 October 2026.
Want this working in your Customer.io workspace?
It's what we do all day for SMBs—strategy, automations, deliverability and hands-on execution.
See how we work as a Customer.io agency →
