Security
The boring kind of safe.
We hold orders, customer answers and payment references. Here is exactly how, in rules you could check rather than adjectives you would have to trust.
Row-level security, on by default
Every table gets row-level security unless there is a written reason it cannot.
Not a convention — the default, applied at the database rather than in the application layer above it. A query that forgets to scope itself to your workspace returns nothing, instead of returning somebody else's rows. The exceptions are the interesting part of a security model, so ours have to be written down to exist at all.
Capture is a read, not a connection
Nobody logs in. No partner grants us access. Nothing is installed on their account.
We read what is already public, on your behalf. A creator you work with never hands over a password, an OAuth grant, or an account. That is a smaller product surface than the alternative and a much smaller thing to lose: there is no partner credential in our system to leak, because we never asked for one.
Your history stays yours, in full
Every reading is kept for 365 days at full detail — no averaging, no downsampling.
Metrics are not thinned as they age and are not rolled up into a summary you cannot unpick. You can export the lot at any point. A platform that quietly degrades your history is one you cannot leave, and we would rather be one you stay with.
We never hold a card
Billing and incentive settlement run through Stripe.
Card details go to Stripe and stay there; we hold a customer reference and nothing that could be used to charge anyone. The same rails settle incentives out, so a reward you promise a customer is paid by a payment processor rather than by a script we wrote.
Input is validated at the boundary
Every save surface validates through one shared slice before anything is written.
Forms, resolvers and ingest all parse against the same schema, so a shape that is wrong is refused at the wire rather than half-written and cleaned up later. Failures come back as errors on the response, never as a partial record you have to go and find.
A question this page does not answer — a DPA, a sub-processor list, where a region’s data sits — is one worth asking directly. Write to us and you will get a real answer rather than a form.