Data residency is the question of which jurisdiction your data is stored and processed in. It matters because European data protection law treats a transfer outside the EU as something that needs its own basis, so where a provider keeps your recipients' data is a compliance fact rather than an infrastructure detail.
This page describes how it works on Bird. The legal framing around it is in what GDPR requires and what a data processing agreement contains; none of this is legal advice.
Where does my data live?
In one region, chosen when the organization is created.
Every Bird organization is assigned a region at signup. us1 is the United States and eu1 is the European Union, and the regions documentation states what that assignment covers:
Every organization is assigned a region at signup. The region is detected from your location, can be changed before you confirm, and is immutable in v1. The workspace, API keys, messages, recipient data, and event logs remain in that region. They are never replicated across regions.
The phrase to weigh is "never replicated". A residency commitment that permitted a copy elsewhere for redundancy or analytics would not be one. Here the data plane is genuinely separate per region, which is also why the choice is immutable: moving an organization between regions is not a setting, it is a migration that the current API version does not offer.
How is it enforced?
In the credential and in the routing, so that a mistake fails loudly.
There is no single global endpoint for the data plane. Each region has its own host, and an API key names its region in its prefix: a bk_eu1_ key belongs to eu1. The SDKs and the CLI read the prefix and pick the host without configuration.
What happens when a request goes to the wrong place is the interesting part:
A request that reaches the wrong region is rejected with
421 Misdirected Requestinstead of being forwarded. The error message names the correct host
Refusing rather than forwarding is the design decision that makes residency verifiable. A platform that silently proxied a misdirected request would be convenient and would also mean a request carrying personal data had crossed a boundary before anyone noticed. Here it cannot: the request fails, and the error names the host to use.
Every response also carries an X-Bird-Region header naming the region that served it, so you can confirm where a call actually landed rather than trusting the configuration.
What is not region-bound?
Authentication and account administration, and the documentation says so rather than leaving it implicit:
Only authentication and account administration (
/v1/auth,/v1/admin) operate on globally replicated data, which is why they are served from the non-region hostplatform.bird.com.
This is worth knowing rather than glossing. Signing in and managing an account touch identity data that has to work from anywhere, so those two surfaces are global by design while everything about messages and recipients is not. If you are documenting your own data flows, that split is the boundary to draw.
Does residency decide where my messages go?
No, and conflating the two leads to the wrong conclusion in both directions.
Residency is where your data is stored and processed. Delivery is about where your recipients are, which is governed by coverage, local rules and sanctions. An eu1 organization can send to recipients anywhere Bird delivers, and a us1 organization can send to European recipients. Supported countries and restrictions covers the delivery side.
What residency does decide is where the record of that message lives afterwards: the message itself, the recipient data, the event log. That record is usually what a data protection question is actually about.
What should I decide up front?
The region, because it is the one part of this you cannot revisit.
Since the assignment is immutable once confirmed, region selection belongs in whatever process creates your production organization, alongside anything else that is decided once. A test organization created in the wrong region is a small annoyance; a production one is a migration.
Two related things to settle at the same time, since they travel together in most reviews: the data processing agreement that governs the relationship, and where the provider publishes its sub-processor list, since a sub-processor in another jurisdiction is a transfer question that residency alone does not answer.