Skip to content
Chumbaq

How we look after your users' data

What we store, where it lives, who can reach it, and what we don't have yet.

No SOC 2 report yet. We're a young company and we won't pretend otherwise. If you need your data to stay in your own infrastructure, self-host Chumbaq.

What we store

  • The user IDs, traits and events your app sends.
  • Email addresses, phone numbers and opt-in choices, when your app sends them.
  • Device push tokens, and which devices are reachable.
  • Clicks on your links, with the IP address and device details we use to match an install to its click.
  • Your campaigns, segments, journeys and their results.
  • Credentials for your push, email, SMS and WhatsApp providers. We use them only to send your messages and to check the delivery reports your providers send back.

Where it lives

On our cloud, data is stored with our hosting provider in the region listed on the subprocessors page. When you self-host, it never reaches us.

How we protect it

  • Provider credentials are encrypted at rest with AES-256-GCM.
  • Dashboard sign-in supports passkeys and codes from an authenticator app.
  • When our staff open your account in our admin tools, or view it as you, it is written to an audit log.

API keys

  • Each API key belongs to one project; a key can't read or write another project's data.
  • A key is built into your app, so treat it as visible, not secret. It only works on the endpoints the SDKs use; it can't sign in to the dashboard.
  • Send keys in the x-api-key header, and only over HTTPS.
  • We store a hash of each key, not the key, so you see it once, when you create it.
  • The project owner creates and revokes keys on the project's API Keys page. A revoked key stops working at once.

Your data, your call

  • See each person's traits and events in the dashboard, and download a link's clicks as a CSV.
  • On a person's page in the dashboard, the project owner can Export data, a JSON file of what the project holds about them, or Delete person. Deleting asks you to type the person's id and to have signed in within the last 15 minutes, and our staff can't do it while viewing your account.
  • Your backend can do the same through the API: POST /api/privacy/erasures and POST /api/privacy/exports, with a user id or a device id, using a key with the privacy permission. A privacy key is refused on every SDK endpoint, so it can't be shipped inside an app. Creating one needs a recent sign-in, and we email the project owner when one is made.
  • A deletion runs as one database transaction, so it never stops halfway, and it is safe to repeat: a second request reports that there is nothing left to delete. Each request is written to a log that stores the person's ids only as keyed hashes.
  • Some things are kept on purpose: opt-outs, as one-way hashes, so a person isn't messaged again if their address is added later; campaign totals, as anonymous numbers; and that log entry. Database backups keep data until they expire. Data already sent to your providers (FCM, APNs, your email, SMS and WhatsApp providers, Mixpanel, your webhooks) must be deleted there. The full list is on our DPDP page.
  • Email, SMS and WhatsApp sends skip anyone who has opted out of that channel. By default they go only to people who opted in; a project can change that per channel.
  • Every campaign email carries a one-click unsubscribe link.
  • When someone replies STOP to an SMS or WhatsApp message, we stop sending to that number on that channel.
  • Push sends skip any device whose user turned push off in your app, on every kind of send, test sends included.
  • When your app sets do-not-track on a device, we stop storing that device's events, sessions, location and campaign sources, and its behaviour stops counting in segments (saved segments catch up at their next refresh). We keep only receipts for messages already sent. Do-not-track doesn't stop messages; each channel's own opt-in does that.
  • Every consent change is recorded with when it happened and where it came from, such as your app, an unsubscribe link or a STOP reply.
  • Our contract and data processing agreement are with Qleverlabs Technologies Inc or Qleverlabs Technologies Pvt Ltd. See the DPA.

Open source

The SDKs and the server are open source, so you can read every line that touches your users' data.

Report a problem

Found a vulnerability? Email hello@chumbaq.com with “Security” in the subject. We reply within two working days.

Bring your users back

Free up to 2,500 monthly active users. No card, no sales call.