Last updated

Privacy Policy

Kanca records metadata about how an ikas app behaves, not the data flowing through it. This page says exactly what we store, why, for how long, and who else touches it.

01Who we are

Kanca (kanca.onurhan.dev) is operated by Onurhan Demir, an individual. Questions and requests about your data go to onurhandtr@gmail.com.

02Two kinds of data

Kanca handles two different kinds of data, and our role is different for each:

  • Account data about you, the developer who signs up. We decide how it is used, so we are the controller.
  • Event data your ikas app sends through the @kanca-app/ikas SDK. You decide what your app sends and why; we process it only to show it to you. For this data you are the controller and Kanca acts as your processor.

If your app is used by ikas merchants, telling them about monitoring (for example in your own privacy notice) is your responsibility.

03Your account

  • Name and email you enter when you sign up. If you leave the name empty, the part of your email before the @ is used.
  • Password, stored only as a hash. We cannot read it.
  • GitHub sign-in, if you choose it: your GitHub account id, name, email and avatar URL, and the OAuth tokens GitHub issues at sign-in, which our authentication library stores with your account. Kanca does not use them to access your GitHub account.
  • Sessions: for each sign-in, a session token, its expiry, and the IP address and browser user agent of the device you signed in from.
  • Projects: name, timezone, when the first and latest event arrived, and when you deleted (deactivated) the project, if you did.
  • API keys: a SHA-256 hash of each key, its first few characters for display, its label, its allowed origins, and when it was created, last used and revoked. The full key is shown to you once and is not stored.
  • Alert channels: the Slack or Discord incoming webhook URL you add, whether it is enabled, and the time and error of the last delivery attempt.

04What your ikas app sends

The SDK sends operational metadata only, as defined in the ingest protocol. Per event, that can be:

  • Event type and name: a webhook scope (e.g. store/order/created), a GraphQL operation name, the method, host and path of an HTTP call you wrap (never the query string), an OAuth call label, a web vital name, or a storefront event name.
  • When it happened, HTTP status, success or failure, duration, and a web vital or load-size value.
  • An error code and a short error message (at most 500 characters; storefront messages are scrubbed by the SDK of URL queries, email addresses, ids, long digit runs and tokens, and cut to 300).
  • The ikas merchant id, store name and webhook delivery id.
  • For admin web vitals: the page path (no query), the rating, and whether the page ran inside the ikas admin (in a frame) or in its own tab.
  • For the daily install check: how many stores were checked, installed, uninstalled or unknown, and short reason codes for the unknown ones (such as HTTP_401 or TOKEN_EXPIRED).
  • For the storefront script: the site's hostname, a path pattern with ids, emails and tokens replaced, the script name and release, a random page-view id that is not stored in the browser, the sample rate, load size and timing, and the file, line and column where an error was thrown.

We also record when each event was received, and keep a per-store install status derived from these events.

Never sent and never stored:

  • Webhook payloads or signatures.
  • GraphQL queries, variables or responses.
  • Request headers, ikas access or refresh tokens, client secrets, query strings.
  • Customer, cart or order data, and storefront visitors' cookies or browser storage.

Store names and merchant ids identify merchants' stores; for a sole trader that can be personal data. The SDK is designed to send nothing else, but free-text fields (names, error messages, attributes) contain whatever your code puts there, so don't put personal data in them.

When a browser sends events with a public key, its IP address is used in memory for rate limiting and is not stored.

05How we use data

We use data only to run Kanca:

  • to sign you in and keep you signed in;
  • to show your dashboards, stores and events;
  • to post alerts to the Slack or Discord channels you set up. An alert carries the project name, the rule, the numbers behind it and a link, never event payloads or store names;
  • to keep the service secure and protect the ingest endpoints from abuse.

We don't sell data, show ads, build profiles, or send marketing email. Kanca does not send email at all. Under the GDPR and KVKK, account data is processed to provide the service you signed up for, and security data on the basis of our legitimate interest in keeping it running safely. Event data is processed on your instructions.

06Where it is stored

Kanca runs on a single server rented from Hetzner Online GmbH in Helsinki, Finland (EU). The application and its Postgres database, which holds all of the data on this page, run on that same server.

The database is backed up once a day, and the backups are kept on the same server (the latest 14). There are no copies with any other backup or storage provider today. If that changes, this page will be updated.

07How long we keep it

Nothing is deleted automatically after a fixed period. Data is kept for as long as your account and the project it belongs to exist.

  • Deleting a project in Settings deactivates it: it disappears from your account, its keys stop working, no new events are accepted and no alerts are sent. Its data (events, store records, hashed keys and alert channels) is kept until you ask us to delete it.
  • Permanent deletion: email onurhandtr@gmail.com from your account's address and say which project, or that you want your whole account deleted. We delete it within 30 days and reply to confirm when it is done. Deleting a project removes it with its events, store records, keys and alert channels; deleting your account removes it with your sessions, sign-in methods and all of your projects and their data.
  • Backups: deleted data can remain in the daily backups until they are replaced, at most 14 days later.
  • Deletion record: when we delete a project or an account, we keep a record that we did it: the project name or the account's email address, its id, and the date.
  • Sessions: a session is removed when you sign out, and in any case deleted with your account.

08Cookies and local storage

Kanca uses only cookies it needs to work:

  • a session cookie set by our authentication library (Better Auth) that keeps you signed in, plus short-lived cookies during GitHub sign-in;
  • a 10-minute, encrypted, HTTP-only cookie that hands a new project's keys to its setup page once, then is deleted.

Your light or dark theme choice is kept in your browser's local storage. There are no analytics, tracking or advertising cookies and no third-party analytics scripts. Fonts are served from our own domain.

The storefront SDK sets no cookies and reads no browser storage on merchants' storefronts.

09Who else processes it

  • Hetzner Online GmbH rents us the server in Helsinki, Finland that Kanca, its database and its backups run on (deployed with Coolify, which we run ourselves).
  • GitHub, only if you choose to sign in with GitHub.
  • Slack and Discord, only for the alert messages sent to channels you configure.

GitHub, Slack and Discord are based outside Turkey and the EU and process what they receive under their own terms. We don't share data with anyone else, unless the law requires us to.

10Security

Passwords and API keys are stored only as hashes. Alert webhook URLs stay on the server; the dashboard only ever shows a masked form. The service is served over HTTPS. No system is perfectly secure; if we learn of a breach that affects your data, we will tell you.

11Your rights

Under the EU GDPR and Turkey's Personal Data Protection Law (KVKK, Law No. 6698) you can ask us to:

  • tell you whether we hold data about you and give you a copy;
  • correct data that is wrong;
  • delete your data permanently (see How long we keep it);
  • stop or restrict processing you object to;
  • give you your data in a machine-readable format.

Email onurhandtr@gmail.com. We answer within 30 days. You can also complain to your data protection authority (in Turkey, the Personal Data Protection Authority, KVKK).

If you are a merchant and your store's data reached Kanca through an app, contact that app's developer first: they control that data. We will help them answer you.

12Changes to this policy

If this policy changes, we update this page and the date at the top. The Terms of Service cover the rest of the rules for using Kanca.

13Contact

Onurhan Demir, onurhandtr@gmail.com.