How we handle your customer data
You are connecting other people’s customers to us — their payments, their support conversations, their sign-ups. This page says what actually happens to that data, and what we do not do yet.
What is in place
Your connector secrets are encrypted before they are stored
The signing secret for each source is wrapped with AES-GCM under a key held as a write-only Worker secret, with a fresh 12-byte IV per encryption. The ingestion Worker refuses to use any connector row that is not wrapped, so an unencrypted secret cannot be introduced by accident.
Sign-in links and session tokens are never stored
Only a SHA-256 hash of each is written to the database, and lookup is by hash. Read access to our tables is not the ability to sign in as anyone. Sign-in links expire after 15 minutes and are single-use, enforced by the changed-row count of a conditional update rather than a read-then-write.
Session cookies are host-locked
Sessions use the __Host- cookie prefix, which makes the browser refuse the cookie unless it is Secure, Path=/ and carries no Domain attribute. A sibling subdomain cannot set or read it. Sessions last 30 days and rotate, with the previous token recorded so a chain is readable during an incident.
We do not store your IP address
Addresses used for abuse rate-limiting are hashed and truncated to 64 bits before anything is written. The raw address is never persisted, and the truncated hash is not reversible to one visitor.
Every read is scoped to a teamspace you belong to
The teamspace id is resolved from a verified membership row for the signed-in account, never from a cookie, URL segment or form field. A tampered value degrades to your own teamspace rather than selecting someone else's.
Inbound webhooks are verified before anything is written
Stripe requests are checked against Stripe's own timestamped signature, which expires after five minutes so a replayed request is rejected. Intercom, Firebase and GA4 are verified by an HMAC over the exact request body. An unverified request is refused at the door.
The raw payload is kept, unmodified
Every accepted webhook body is written to object storage before it is interpreted, keyed so that redelivering the same payload cannot create a second copy. If we ever parse something wrongly, the original is still there to reprocess.
What we do not offer
Listed because you would otherwise have to ask, and because assuming any of these exists is a worse outcome for you than reading it here.
- We do not hold a SOC 2 report or an ISO 27001 certificate.
- We do not currently offer a signed DPA or a custom security review.
- There is no published uptime SLA.
- Data is stored on Cloudflare's global network; we do not currently offer region pinning.
Who else touches the data
The complete list. Anything not named here does not receive your customer data.
Cloudflare
Runs the application and the ingestion endpoint, and stores everything: profiles and events in D1, raw source payloads in R2, and the delivery queue.
Resend
Delivers sign-in links and teamspace invitations. Receives the recipient address and the message; it is not sent customer profile data.
Also published as a standalone subprocessor list, so you can link procurement straight to it.
Reporting a vulnerability
Email contact@customerspine.com with enough detail to reproduce it. We will confirm we have read it. Please do not run automated scans against the ingestion endpoint — it is rate-limited and you will mostly be testing the limiter.