Multi-tenant vault
Every customer gets a BoxOwl vault scoped to their user ID. Row-level isolation, typed IDs, predictable lookups.
Personal Data, as a Service.
A consented, multi-tenant vault for every customer — held on BoxOwl, accessed by your app through a REST API. You build the product. We hold the data.
PDaaS is the paid tier of the two-tier SMRT protocol. Establishing a connection (the consent flow below) flips the user's extension from injecting anonymous SMRT signals to injecting a per-org identity JWT — your server recognizes the user on every request, no callback. The data API on this page covers everything beyond what the JWT carries.
GET /api/v1/connect/users/{handle}/address/primary
{
"street": "248 Sumac Ave",
"cityTown": "Portland",
"stateProvince": "OR",
"postalCode": "97214",
"country": "US"
}
// scoped to the connection's granted PDaaS scopes
// every read audit-logged: actor · IP · key id
What PDaaS provides
The data layer, already built.
You bring the application. We provide the vault, the compliance, and the API.
Consent-gated reads
Every API call requires an active customer grant. Revocations are instant and audit-logged on both sides.
Scoped API keys
Generate keys per environment with least-privilege scopes. Rotate without downtime, revoke from the dashboard.
Compliance built in
CCPA/CPRA-ready export and erasure endpoints. GDPR data processor obligations satisfied. DPA out of the box.
Webhook events
Subscribe to connection and deletion-lifecycle events: customer.connection-established, customer.connection-revoked, customer.vault.updated, plus the 30-day deletion lifecycle.
Audit by default
Every read, write, and delete is logged with actor, timestamp, IP, and key ID. Paginated audit-log API for review.
Architecture
How PDaaS sits in your stack.
Your application talks to BoxOwl. BoxOwl holds the vault. Customers manage consent from their BoxOwl app.
Connect flow → grant code → scope-filtered profile reads · webhooks on connect, revoke, scope changes & deletion
How it works
Five steps to integrate.
From beta token to live customer vaults — typically a day of work.
Register your app & get an API key
BoxOwl registers your app: slug, display name, allowed redirect URIs, allowed iframe parent origins. You receive a bxorg_* API key your backend stores. The key never enters browser JS — only your server-to-server calls use it.
Send users through the Connect flow
Send "Sign in with BoxOwl" to api.boxowl.me/connect?app=&scopes=identity.name,address.primary,…&return=&state=&pkce_challenge=. The user signs in (if not already), sees a consent screen for the scopes you requested, grants or denies, lands back on your return with a single-use grant code. PKCE is mandatory; an iframe-embedded variant at /connect/embed keeps users in your app's chrome.
Exchange the code for a connection
Your backend POSTs {code, codeVerifier} to /api/v1/connect/exchange with your API key. You receive a handle, connectionId, and the canonical scope list the user granted. Bind to your session.
Read profile data on demand
Call GET /api/v1/connect/users/{handle}/profile with your API key. The response is keyed by scope namespace (identity, contact, address, social, preferences, work) — only scopes the user actually granted appear. Requesting an ungranted scope returns 403 scope_missing; every call is recorded in the user-visible access audit log.
Respond to webhooks
Handle the HMAC-signed payloads: customer.connection-established, customer.connection-revoked, customer.connection-updated (scope changes), customer.re-consent.required (your app's request widened and the user needs to re-consent before next fetch), and customer.vault.updated. Stay in sync without polling.
Recognition without a callback
The identity JWT is the per-request handshake.
Once a connection exists, the extension injects X-BoxOwl-Identity on every request to your domain. Your server verifies the JWT locally via JWKS and reads name, verified, and the pairwise orgUid — no callback to BoxOwl, no per-request API hit. The data API (above) covers anything beyond what the JWT carries.
A request from a connected user
// JWT payload (verified via /.well-known/smrt-jwks.json) { "sub": "ouid-alice-yourshop-1", // pairwise orgUid "name": "Alice Smith", "verified": true, "tier": "pdaas", "org": "your-shop", // verify this matches your slug "smrt": { /* preference profile */ }, "iss": "boxowl.me", "exp": 1748392200 }
Two orgs see different orgUid values for the same user — pairwise UIDs prevent cross-org correlation by design.
See the SMRT API docs for the full claim table and the JWKS verification path.
Included with PDaaS
Silent customer matching with
Silent customer matching with tags.
For orgs that already have a customer database. Match BoxOwl users to your own records silently, without asking the user to log in or wait on an API call. Ships as part of standard PDaaS — no separate tier, no add-on.
How silent matching works
- User goes through the standard PDaaS
/connectflow → connection created, BoxOwl mints a stableorgUidfor your org. - Your backend immediately calls
POST /api/v1/orgs/{slug}/connections/{orgUid}/tagswith your internal customer-id and any other annotations. - On every subsequent visit, the identity JWT carries the
tagsclaim. Readtags.customerId, look it up in your DB, render full customer context. Zero callbacks.
The tags claim. Org-stored key→value pairs (e.g., customerId, memberTier) set at connect-time. They ride inside the Identity JWT on every visit so your server can recognize "Customer #C123, Gold tier" before a single DB lookup.
Live propagation. customer.vault.user-updated fires the moment a consented field changes in BoxOwl, with the changes and the orgUid — so your CRM stays current without polling.
Batch sync API. POST /api/v1/pdaas/true/sync for reconciliation; GET /api/v1/pdaas/true/events?since= for missed-events recovery.
See pricing for the meter table (orgUid mints, propagation webhooks, sync calls) or read the silent-matching developer docs.
Build vs. Buy
Skip the year of plumbing.
Personal-data infrastructure is a project. PDaaS is a checkout.
Building it yourself
- Months of compliance research
- CCPA/CPRA data mapping
- GDPR DSAR pipeline
- Encryption at rest and in transit
- Audit logging infrastructure
- Consent management UI
- Webhook delivery infrastructure
- Ongoing security audits
Using PDaaS
- REST API live in minutes
- CCPA/CPRA & GDPR-aligned design
- User-controlled DSAR export & deletion lifecycle
- Encryption handled by BoxOwl
- Paginated audit-log API
- Customers manage consent in their BoxOwl app
- HMAC-signed webhooks delivered to your endpoint
- Hosted consent UI — no consent flow to build
The platform handles the hard part.
Consent, audit, and the deletion lifecycle are the deal. Your team focuses on the product.
Encryption at rest
Postgres on LUKS-encrypted volumes; E2EE for payment methods and secure notes.
Consent is the gate
Every read scoped to the categories the user explicitly granted to your org.
Audit by default
Every read, write, and revoke is logged with actor, time, IP, and key id.
Deletion lifecycle
30-day pending → confirmed/cancelled webhooks keep your records in sync with the user's choice.
See it live
PDaaS powering a real checkout flow.
The BoxOwl Store (store.boxowl.me) is a shop built by the BoxOwl team that uses PDaaS to pull shipping address and identity from the user's vault at checkout — no forms, no stored copies.
After a one-tap BoxOwl connect, the store uses a scoped bxorg_* API key
to read identity and address at checkout time.
Every read is audit-logged. Revoke from the BoxOwl app and the webhook immediately clears the store's connection.
Ready to integrate?
PDaaS is in private beta. Request an organization token below, or read the API docs first.
Not building an app? See features for individuals →