Data storage, isolation and controls
Where partner data lives, how it is encrypted, and how access is bounded to your organization.
What a security reviewer usually wants to know before a partner integration is signed off.
Where it runs
Journey's API, its operational database, database backups and the analytics
datasets behind them all run in Google Cloud's us-east1 region.
The API itself runs on Cloud Run behind Cloudflare, with a dedicated service account and all egress routed through a VPC.
Where data sits
Raw PMS extracts
Newline-delimited JSON in Google Cloud Storage, partitioned by chain, date and time.
Analytics
BigQuery datasets — raw per-PMS datasets, and the modelled marts that dbt builds from them.
Operational store
AlloyDB for PostgreSQL 16, which is what the Partner API reads and writes. It runs as a primary with a read replica.
Encryption and access
| Control | How it works |
|---|---|
| In transit (API) | HTTPS to the API, terminated at the edge. |
| In transit (database) | AlloyDB is configured for encrypted connections only, on both the primary and the replica. |
| At rest | Google-managed encryption, applied by default across storage, BigQuery and the database. Journey does not currently configure customer-managed keys. |
| Network | The database has no public IP — private networking only. |
| Database authentication | IAM database authentication is enabled, so access is granted to identities rather than shared passwords. |
| Object storage | Uniform bucket-level access, public access prevention enforced, and create-only writes so an extract cannot overwrite history. |
| Backups | Continuous backup with point-in-time recovery, plus automated backups, held in the same region. |
How your data is isolated from other partners'
This is enforced in the API, on every request, rather than relying on callers to filter correctly.
Your organization comes from your credential
Not from a parameter. A partner caller cannot pass ?organizationId — it
is ignored. A credential with no organization is rejected outright.
Venue reach narrows it further
Role restrictions on your credential can limit it to particular properties or brands within your organization. Reads are filtered to that allowlist.
Out of scope looks like not found
Anything outside your organization and venue reach returns 404, not 403, so the response cannot be used to probe for what exists elsewhere.
Personal data
- Guest contact details are masked by default. Guest name, email and phone are only returned if your credential carries the guest PII read permission. Without it the fields are present but masked, which is a scope question rather than a data-availability one.
- PII is labelled internally. The reservations mart is tagged as containing personal data so that downstream tooling can treat it accordingly.
- Invite sending is the narrow exception. Guest invites deliberately touch contact details, and require the PII permission in addition to the general guest read permission.
Credential handling
X-API-Keyis not in the API's CORS allow-list. This is deliberate: partner keys are for server-to-server use and must never be exposed to a browser.- Only partner-level and admin-level keys are accepted on the partner surface. A service-level key is rejected.
- Revoked and expired keys stop working immediately, returning
401.
A partner key carries access to guest data across your whole organization. Keep it server-side, in a secret manager, and rotate by issuing a replacement before revoking the old one.
What is not covered here
Data retention schedules for raw extracts and analytics tables, and the specifics of Journey's internal access reviews, are governed by Journey's security policies rather than by the API. Ask your Journey contact if you need them for a security review.