The communication data path
| Stage | System | Data and location |
|---|---|---|
| 1Account and project | Boundry app, Clerk, control database | User identity, organisation membership, project directory, selected region, and configuration metadata. Communication content is not stored in this directory. |
| 2API ingress | api.au.boundry.dev | Customer requests enter the Sydney regional service. Cloudflare may be in the network path for the hostname. |
| 3Regional processing | Laravel Cloud, Sydney | Validation, project authorisation, queue coordination, webhook processing, and regional service execution in ap-southeast-2. |
| 4Storage and queues | Regional PostgreSQL and designated object storage | Message content, recipients, attachments, source artifacts, events, suppressions, inbound data, logs, queues, and provider state belong to the Sydney data plane. |
| 5Provider handoff | Amazon SES, Sydney | The message is submitted to SES in ap-southeast-2. SES then transfers it toward the recipient’s mailbox provider. |
| 6Delivery events | Amazon SNS and regional API | Signed provider events return through the Sydney SNS topic and are verified before regional records are updated. |
| 7Customer webhooks | Regional worker to customer endpoint | Signed event payloads leave Sydney for the endpoint selected by the customer. The customer controls that destination. |
| 8Recipient mailbox | Recipient-controlled provider | Outside the Boundry boundary. Its location and retention are determined by the recipient and their provider. |
Data at rest
Regional storage is more than the final message table. The boundary includes the systems that can preserve sensitive information while no request is active.
- regional PostgreSQL message and operational records;
- database-backed regional queues;
- designated S3 object storage for archives and attachments;
- inbound source objects when native inbound is enabled;
- delivery events, webhook attempts, suppressions, and request logs; and
- backups created by managed infrastructure providers.
Production proof for encryption settings, backup location, backup retention, restore behaviour, and deletion from backup media is still being assembled. Until that evidence is complete, Boundry does not describe the entire at-rest lifecycle as independently verified.
Data in transit
Public Boundry application and regional API endpoints use HTTPS. Dashboard content requests go directly from the browser to the regional API using a short-lived, project-scoped token. Customer API requests do not need a control-plane content proxy.
After SES accepts a message in Sydney, ordinary internet email routing takes it to the recipient's infrastructure. Boundry cannot truthfully promise that this delivery path or the destination mailbox remains in Australia.
Access and isolation
- Each project belongs to exactly one enabled region.
- Regional credentials are scoped to a project.
- Raw API keys are displayed once and stored as hashes.
- Dashboard regional credentials are signed, short-lived, and held in browser memory.
- The regional API does not receive credentials for the Boundry control database.
- Provider callbacks are signature checked and topic restricted.
Retention and deletion
Customer-configurable retention and automated deletion are not implemented or enforced. The website does not present a retention setting as an available control.
Backup location, restoration behaviour, backup retention, and deletion from backup media also require operational evidence before Boundry can publish an end-to-end deletion commitment.
Known exceptions
Identity and organisations
Clerk handles user identity, sessions, and organisation membership outside the regional communication database.
Recipient infrastructure
Delivery leaves the boundary when SES transfers the message to the recipient's mail system.
Backups and observability
Complete provider evidence for backups, logs, telemetry, and selective deletion is not yet published.
Webhook destinations
Signed event data goes to the endpoint a customer configures. Its location and storage are the customer's responsibility.
Subprocessors
The current providers, purposes, and boundary roles are maintained in the subprocessor register. Material changes are reflected there and in this manifest.