Data Residency

Regional deployment endpoints, data-flow boundaries, and practical planning considerations for regulated deployments.

The region reported by the Platform API identifies the deployment serving the request. It is not an editable workspace placement policy or proof that every system involved in the workflow processes data in that region. Agree on the actual regional data and service boundary when provisioning a deployment.

Regional Endpoints

Deployment region	Platform API endpoint
US East	platform.api-us.concurrence.com
Canada Central	platform.api-ca.concurrence.com
EU Central	platform.api-eu.concurrence.com
Australia Southeast	platform.api-au.concurrence.com

platform.api-us.concurrence.com is the canonical US endpoint, not a global router. To create or access a workspace in another supported region, use the endpoint assigned to that regional deployment. Set the Platform TypeScript SDK's baseUrl explicitly; its current default still points to the legacy US hostname. Identity and other services have separate hosts listed in Regions and Endpoints.

Regional service availability can differ. Confirm that the channels, connectors, models, and supporting services required by your deployment are available in the target region before provisioning production workloads.

Workspace Placement

Workspace creation does not select a region independently of the deployment endpoint. The workspace update path still accepts a legacy region value for compatibility but ignores it; a successful update does not move data or change the region reported by the serving deployment.

Concurrence does not currently expose a self-service cross-region workspace migration. Organizations operating in multiple regions should plan separate workspaces and configuration promotion for each region.

What the Boundary Covers

For customer-account requirements, use Cloud Ownership and Integration Boundaries to separate software ownership, processing, storage, operator access, and billing. Regional placement and query federation alone do not establish that all data and compute remain in the customer's account.

Region placement applies to Concurrence-managed workspace data and regional services that are provisioned for that workspace. Workspace authorization remains a separate control: region placement does not replace tenant isolation, role-based access, or resource-level permission checks.

Some workflows intentionally communicate with systems outside Concurrence's managed regional boundary, including:

• Customer-hosted EHR, CRM, and integration endpoints
• Telephony, messaging, email, and identity providers
• Model, speech, and infrastructure providers used by Concurrence or selected by the customer
• Operator browsers and customer applications

Those systems have their own processing locations, retention policies, and transfer mechanisms. Connector traffic also follows the location of the customer endpoint. Review the complete data flow rather than treating the workspace region as an end-to-end residency guarantee.

A configured model can route requests to more than one hosting provider, including a fallback provider. Confirm the permitted providers and processing locations for both normal operation and fallback. A model name or regional API hostname alone does not establish where inference runs.

Multi-Region Planning

For organizations serving more than one jurisdiction:

1. Choose the regional endpoint before creating each workspace.
2. Keep patient and operational data in the workspace intended for that jurisdiction.
3. Promote agent configuration separately to each workspace.
4. Provision regional channel resources and connector credentials independently.
5. Validate every subprocessor and external integration against the intended data-flow boundary.

Entities and conversations in separate workspaces remain separate unless your own integration deliberately transfers or reconciles them. Do not assume automatic cross-region identity matching or configuration synchronization.

Compliance Planning

Region choice is one input to a compliance program, not a certification by itself. Applicable requirements depend on the organization, data, purpose, external systems, and contractual terms involved in the deployment.

Before production launch, confirm with Concurrence:

• The services available in the requested region
• The managed-data boundary for each channel and connector
• Encryption, retention, deletion, and backup requirements
• Required contractual terms and subprocessors
• Any approved cross-border transfer mechanism

See Compliance and Audit for documented platform controls, and Deployment Model for workspace-isolation patterns.