Consent & data privacy (GDPR/CCPA)
This article explains the privacy and consent concepts that apply to every channel you send on through Bird: what consent means, what GDPR and CCPA expect of you, where your data physically lives, and how to handle requests from the people you message. It is guidance to help you understand your obligations — not legal advice, and not the contract. The terms that actually govern how Bird processes your data are in Bird's legal agreements (including the Data Processing Agreement and privacy policy); where this article and those differ, the agreements win. For requirements specific to your business, talk to your own legal counsel.
Channel-specific rules (like CAN-SPAM for email) build on top of these basics. See Email · list consent & CAN-SPAM for the email-specific article.
Who is responsible for what
Privacy law splits responsibility between two roles, and it helps to be clear about which one is yours:
- You are the controller. You decide who to message, why, and what data about them to keep. The people you message are your customers, and the legal obligations to them — collecting consent, honoring opt-outs, answering privacy requests — are yours.
- Bird is the processor. Bird stores and processes contact data on your instructions to deliver your messages. Bird does not message your contacts on its own behalf or use their data for its own purposes.
In practice this means privacy requests from your recipients go to you, and you use Bird's tools and APIs to carry them out.
Consent: get it, record it, honor it
Whatever channel you use, the same three habits keep you on the right side of both the law and your recipients:
- Get consent before you message. The person should have taken a clear action that signals they want to hear from you — checking a box, submitting a signup form, replying to a keyword. Pre-ticked boxes and silence do not count as consent under GDPR, and buying or scraping contact lists means you never had consent at all.
- Record the consent. Keep a record of who consented, when, how (which form, which page, which checkbox text), and to what. If a recipient or a regulator ever asks "why are you messaging me?", that record is your answer. Bird does not capture this for you — consent happens in your product, so the record lives in your systems.
- Honor withdrawals immediately. Consent can be taken back at any time, and once it is, marketing messages must stop. On email, Bird automates a large part of this: unsubscribes and spam complaints automatically suppress the address for broadcast mail (see the email consent article).
GDPR and CCPA at a glance
The two regimes overlap heavily for messaging. The short version of what each expects:
GDPR (EU/EEA recipients) requires a lawful basis for processing personal data — for marketing messages that basis is almost always consent. It gives individuals rights to access, correct, export, and erase their data, and to object to processing. Requests must generally be answered within one month.
CCPA/CPRA (California recipients) gives consumers the right to know what personal information you collect, to delete it, and to opt out of its sale or sharing. It is more opt-out-shaped than GDPR's opt-in model, but the operational work — finding a person's data and deleting it on request — is the same.
If you message people in both regions, the practical approach is to build to the stricter standard (opt-in consent, full deletion support) and apply it everywhere.
Data residency: your data stays in your region
Every Bird organization is pinned to a single region at signup — us1 (United States) or eu1 (European Union) — and all of the organization's workspaces, messages, contact data, and event logs are stored and processed in that one region. Data is never replicated across regions, which is what makes residency commitments provable: an EU organization's data lives in the EU, full stop.
If your privacy posture requires EU data residency (commonly the case for GDPR-driven processing), choose eu1 at signup. The assignment is immutable, so this is a decision to make up front. See Base URLs & regions for how the region model works at the API level.
Handling data-subject and deletion requests
When a recipient exercises a privacy right — most commonly the right to erasure — you are the one who answers, and you carry the request out across every system that holds their data, including Bird:
- Access and export requests. Use the dashboard or the APIs to retrieve what Bird holds about an address: message history, event logs, and any suppression records.
- Deletion requests. Remove the contact's data from each Bird surface that holds it. One step that is easy to miss: suppression records contain the email address and are your responsibility to erase too. Deleting a suppression is a hard delete — Bird retains nothing afterward — which is exactly what an erasure request needs, but it also means the address becomes sendable again. After honoring an erasure request, make sure your own systems do not re-import or re-message the contact. The mechanics are in the suppressions developer guide.
A reasonable internal checklist for an erasure request: stop active sends to the contact, delete them from your contact lists, delete their suppression records in Bird, delete them from your own databases, and record that the request was completed and when.
Per-channel compliance articles
Each channel adds its own rules on top of these basics:
- Email · list consent & CAN-SPAM — CAN-SPAM requirements, valid list consent, and unsubscribe obligations.
- Email · sender vetting & domain registration — what happens after you add a sending domain.