La región que eliges controla dónde Bird almacena y procesa los datos de tu organización. También afecta qué reglas de privacidad transfronteriza aplican.
¿Dónde residen mis datos?
En una sola región, elegida al crear la organización.
A cada organización de Bird se le asigna una región al registrarse. us1 es Estados Unidos y eu1 es la Unión Europea, y la documentación de regiones indica qué cubre esa asignación:
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.
La frase clave es "never replicated". Un compromiso de residencia que permitiera una copia en otro lugar por redundancia o analítica no sería tal. Aquí el plano de datos está genuinamente separado por región, que es también la razón por la que la elección es inmutable: mover una organización entre regiones no es un ajuste, es una migración que la versión actual de API no ofrece.
¿Cómo se aplica?
En la credencial y en el enrutamiento, para que un error falle de forma evidente.
No existe un único endpoint global para el plano de datos. Cada región tiene su propio host, y una clave de API indica su región en el prefijo: una clave bk_eu1_ pertenece a eu1. Los SDK y CLI leen el prefijo y eligen el host sin configuración adicional.
Lo que ocurre cuando una solicitud llega al lugar incorrecto es la parte interesante:
A request that reaches the wrong region is rejected with
421 Misdirected Requestinstead of being forwarded. The error message names the correct host
Rechazar en lugar de reenviar es la decisión de diseño que hace verificable la residencia. Una plataforma que reenviara silenciosamente una solicitud mal dirigida sería cómoda, pero también significaría que una solicitud con datos personales habría cruzado un límite antes de que alguien lo notara. Aquí eso no puede pasar: la solicitud falla y el error indica el host que debes usar.
Cada respuesta también incluye un encabezado X-Bird-Region que indica la región que la sirvió, para que puedas confirmar dónde aterrizó realmente una llamada en lugar de confiar en la configuración.
¿Qué no está vinculado a una región?
La autenticación y la administración de cuentas, y la documentación lo declara explícitamente en lugar de dejarlo implícito:
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.
Esto vale la pena saberlo en lugar de pasarlo por alto. Iniciar sesión y administrar una cuenta involucran datos de identidad que deben funcionar desde cualquier lugar, así que esas dos superficies son globales por diseño, mientras que todo lo relacionado con mensajes y destinatarios no lo es. Si estás documentando tus propios flujos de datos, esa división es el límite que debes trazar.
¿La residencia decide a dónde van mis mensajes?
No, y confundir ambos conceptos lleva a la conclusión equivocada en ambas direcciones.
La residencia determina dónde se almacenan y procesan tus datos. La entrega se refiere a dónde están tus destinatarios, lo cual depende de la cobertura, las reglas locales y las sanciones. Una organización eu1 puede enviar a destinatarios en cualquier lugar donde Bird entregue, y una organización us1 puede enviar a destinatarios europeos. Países admitidos y restricciones cubre el lado de la entrega.
Lo que la residencia sí decide es dónde queda el registro de ese mensaje después: el mensaje en sí, los datos del destinatario, el registro de eventos. Ese registro suele ser lo que realmente importa en una pregunta sobre protección de datos.
¿Qué debo decidir de antemano?
La región, porque es la única parte de esto que no puedes cambiar después.
Como la asignación es inmutable una vez confirmada, la selección de región pertenece al proceso que crea tu organización de producción, junto con cualquier otra cosa que se decide una sola vez. Una organización de prueba creada en la región incorrecta es una molestia menor; una de producción es una migración.
Dos cosas relacionadas que conviene resolver al mismo tiempo, ya que suelen ir juntas en la mayoría de las revisiones: el acuerdo de procesamiento de datos que rige la relación, y dónde publica el proveedor su lista de subencargados, ya que un subencargado en otra jurisdicción es una cuestión de transferencia que la residencia por sí sola no responde.
En resumen
La residencia es una propiedad de la organización, no de una solicitud.
La región se asigna al registrarse, se puede cambiar antes de confirmar y después es inmutable en la versión actual de API.
Nada se replica entre regiones.
Los espacios de trabajo, las claves, los mensajes, los datos de destinatarios y los registros de eventos permanecen en una sola región, que es lo que hace que un compromiso de residencia signifique algo.
La clave de API lleva su región, y un host incorrecto se rechaza.
Una solicitud que llega a la región incorrecta recibe
421 Misdirected Requestindicando el host correcto, en lugar de reenviarse silenciosamente.Dos superficies son deliberadamente globales.
La autenticación y la administración de cuentas funcionan con datos replicados, por eso responden en un host independiente de la región.