Sub-processors

A sub-processor is a third party that processes personal data on our behalf, because we use its service to run ChartOmodo. This page lists all of them. It is not a sample and not a "such as" list: if a company is not named here, it does not process personal data for us.

We keep this page current. Before we add a sub-processor, we will email you and show an in-app notice at least 30 days before it takes effect, which is the same notice rule as section 13 of the Privacy Policy.

ChartOmodo is built and operated by PT Gagah Sukses Perkasa (ASAK Digital Agency), a company in Indonesia. That is relevant to section 10, so it is worth saying here.

What it is used for: Contabo provides the virtual private server that runs the ChartOmodo application. PostgreSQL runs natively on that same server and is managed by us: it is not a managed database service, so nobody at Contabo administers the database itself. The backups described in section 10 of the Privacy Policy are taken by us on that same server, not by Contabo.

What it receives: everything listed in section 2 of the Privacy Policy, your email address, hashed password, session records, encrypted data source tokens and database credentials, charts and dashboards, billing records and the audit log. Contabo is the infrastructure underneath all of it.

Where it processes it: the European Union (Contabo's EU region). The server, the PostgreSQL database on it and the cached Notion rows written to its filesystem are all in a Contabo data centre in that region, which puts the data listed above at rest inside the EEA. See section 10 for what that does and does not settle about international transfers.

What it is used for: Creem is the merchant of record for every plan paid by card. It runs checkout and the billing portal, manages subscriptions, issues invoices and handles sales tax and VAT.

What it receives: your email address, your card details entered directly into its own hosted checkout, and whatever billing address it needs for tax. Card data never reaches our servers. What comes back to us is a customer ID, a subscription ID, a plan and a status.

Where it processes it: under Creem's own published terms and privacy notice. We do not choose its processing location.

TriPay (operated by PT Trijaya Digital Grup, an Indonesian company): used only when you choose to pay in Rupiah. It runs the hosted QRIS and bank virtual account page and tells us when the payment lands. TriPay is a payment processor, not a merchant of record: for Rupiah plans we are the seller, and no VAT (PPN) is charged because we are not registered for it.

What TriPay receives: your name, your email address and the amount. You pay on its page, and the payment itself is carried by TriPay's bank and QRIS partners and by your own bank or e-wallet; what comes back to us is a payment reference, the channel and a status.

Where TriPay processes it: under TriPay's own published terms and privacy notice. We do not choose its processing location.

What it is used for: address verification when you sign up, the password reset link when you ask for one, Teams invitations and the notice an owner gets when a leaving member's API tokens are revoked, an alert when a connector keeps failing to sync (you can turn that one off under Settings), one email a few days after your first chart that asks what you wanted to chart (sent once; you can turn product emails off under Settings), and, only if you pay in Rupiah, the renewal invoice, one reminder and the receipt. We send no marketing email, so there is no list; the first-chart email asks a question and sells nothing. The connector alert and product emails are the only messages with a switch.

What it receives: your email address and the contents of that message; for the verification, reset and invitation emails that includes a single-use token in a link, and the first-chart email includes your first name when your account has one.

Where it processes it: under Resend's own published terms and sub-processor list.

What it is used for: runtime errors and a sample of performance traces, so crashes get found and fixed.

What it receives: error events and traces. Sentry's "send default PII" option is switched off, so IP addresses and request bodies are not attached. Every outbound event passes through a scrubber that redacts embed tokens, share tokens and password-reset tokens. An event can still incidentally contain a user ID or a database ID inside a stack trace, so we list Sentry as a sub-processor rather than pretend it never sees personal data.

Where it processes it: under Sentry's own published terms and sub-processor list.

What it is used for: counting requests to sign-up, sign-in, password reset and embed endpoints so they can be rate limited.

What it receives: the requesting IP address, as part of a counter key, and a number. It holds no account data, no email addresses and no content.

Where it processes it: under Upstash's own published terms.

What it is used for: Google Analytics 4 counts visits to our public pages (the home page, pricing, features, product, compare, docs, roadmap, support and the legal pages), so we can see which pages and campaigns bring people in. It loads only after a visitor accepts it on the cookie banner, and it is not loaded inside the app, the admin area, the sign-in pages or any embed, and it is switched off the moment a visitor moves from a public page into one of them.

What it receives: the page address, the referrer, a pseudonymous cookie ID, rough device and browser details, and the visitor's IP address, which Google uses to derive a rough location and does not store. It never receives account data, chart data or anything from Notion. Google signals and ad personalisation are off.

Google Sign-In, what it is used for: confirming who you are when you press Continue with Google, instead of a password. Nothing happens with Google unless you press it.

Google Sign-In, what it receives and returns: Google already holds your Google account; it sends us your name, email address, profile photo URL and Google account ID, under the openid, email and profile scopes only. Signing in keeps no Google token, so sign-in alone lets us read nothing else in your Google account. A Google Analytics 4 or Search Console connector is a separate grant you make when you add one; section 9 explains why that is not on this list.

Where it processes it: under Google's own published terms and data processing terms. We do not choose its processing location.

We do not send your data to any large language model provider, and there is no AI processing of your Notion rows, your CSV contents or your account data anywhere in the stack. We are not listing one as "coming soon" either. If that ever changes, it becomes a new sub-processor and gets the 30 days' notice described in section 1.

Reviewers ask about this, so here is the distinction. A sub-processor is a service we chose and engaged to process your data for us. Notion is the opposite: it is your service, holding your data, and you connect it to ChartOmodo by granting us access through an OAuth flow you control. A CSV you upload is the same in kind: your file, handed to us by you. A database you connect is the same again: your server, which we read with credentials you give us.

We are the recipient of that data, not the processor sending it somewhere. Your relationship with Notion is governed by your own agreement with them, not by ours. You can end our access at any time from inside Notion: Settings then Connections then remove ChartOmodo.

The same holds for Google Analytics 4 and Search Console when you connect them as data sources: your Google account, holding your data, which you let us read through Google's consent screen and can disconnect from your Google Account at any time. The Google entry in section 7 covers only visit counts on the public pages and Google Sign-In; connector data is a separate grant that you control.

Practically: if your legal team needs a data processing agreement covering Notion, they need it from Notion. We cannot sign one on Notion's behalf, and listing Notion here would imply a control over it that we do not have.

Start with where the data actually is. Everything in section 2 of the Privacy Policy is at rest on the Contabo server in the EU (inside the EEA). That is the bulk of what we hold, and it does not move.

What crosses a border is access rather than storage. We operate from Indonesia, which has no EU adequacy decision, and the two people with administrative access to that server reach it remotely from there. Under the GDPR that remote access counts as a transfer, so it still needs a safeguard even though the database never leaves the EU.

The remaining providers on this list (Creem, TriPay, Resend, Sentry, Upstash and Google) process in their own locations, which we do not choose. Those are transfers in the ordinary sense, including for data belonging to people in the EU and the UK.

Where our providers offer Standard Contractual Clauses in their data processing agreements, we rely on those clauses. Be aware of what that means in practice: these are the providers' own published DPAs and SCCs, accepted by us as a customer, not clauses negotiated individually, and not a transfer impact assessment produced by a law firm.

We have not obtained an adequacy decision, binding corporate rules or any certification, and we are not going to claim otherwise. If your organisation requires a signed DPA or SCCs directly with us before you can use ChartOmodo, email support@chartomodo.com and say so: we would rather have that conversation than have you assume paperwork exists that does not.

For users in Indonesia the question runs the other way: Indonesia's Personal Data Protection Law (UU 27/2022, Article 56) lets personal data leave the country only to a place with protection at least equal to that law, or under adequate and binding safeguards, or with your consent. The database is in the EU, under the GDPR; for the other providers outside Indonesia we rely on their published data processing terms as the binding safeguard. TriPay is in Indonesia, so paying in Rupiah involves no transfer abroad on its part.

The last-updated date at the top of this page changes whenever this list does.

Adding a sub-processor is a material change to the Privacy Policy. We will email you and show an in-app notice at least 30 days before the new provider starts processing. If you object, you can cancel before it takes effect and we will refund the unused part of your term, as described in section 6 of the Refund Policy.

Removing a sub-processor, or narrowing what one receives, takes effect immediately and needs no notice.

Email support@chartomodo.com for anything on this page: a vendor review question, a request for a data processing agreement, or a correction if something here is out of date. The ChartOmodo team reads that inbox and answers within two business days.

For a suspected vulnerability, use the same address and read Security first for what to include.