Privacy policy

Who runs StudyKaKeyda and what this policy covers

StudyKaKeyda is run by one person. It is not a company. There is no company name, no registration number and no office address, because there is no registered company and no office. Where this policy says “StudyKaKeyda”, it means that one person and the software they run.

StudyKaKeyda is operated from India. Your personal data is handled under the Digital Personal Data Protection Act, 2023 (called “the DPDP Act” below) and the Information Technology Act, 2000. This policy, and any dispute about it, is governed by the law of India.

This policy covers the site at studykakeyda.com, this page at /privacy and the server behind them. The terms of use are at /terms. Two words come up often. “Your browser” means the program you are reading this in; whatever is stored there sits on your own device. “The server” means StudyKaKeyda’s API and its database, which run elsewhere and which StudyKaKeyda can read.

Every statement here describes how the software is built to behave. Where something depends on a setting on the server, or belongs to another company, this policy says so rather than making a promise for them.

In plain words: one person runs StudyKaKeyda from India, Indian data protection law applies, and this page explains what the software really does.

What StudyKaKeyda collects and why

StudyKaKeyda collects as little as it can while still answering your question. There is no advertising, no tracking pixel and no outside analytics service. The only usage counts are StudyKaKeyda’s own, described below, and they go to nobody else. The pages carry no outside script of their own. The only outside code your browser runs is five code libraries from the jsDelivr CDN. They load when you open the code editor, run Python or PHP, view a molecule, or view in 3D a molecule whose shape StudyKaKeyda does not carry itself.

The list below is the whole list. Each item is explained in detail further down.

• What you type or paste: your question, your source code, your program input and your input → output examples. Why: to work out what to show you and to build the visual.
• Photographs of a question. Why: to read the text in the picture so you do not have to type it.
• Account details, if you choose to make an account: your email address, phone number or connected Google or Facebook identity. Why: to sign you in and to keep your history across devices.
• Preferences and layout: theme, accent colour, playback speed, motion setting, explanation language and panel sizes. Why: to keep the app looking and playing the way you left it.
• Usage counts and rate-limit data: how many AI questions an account or a device has asked today. Why: to keep the free daily limit fair and the service available. The numbers built into the software are 20 AI questions a day for a signed-out device and 100 for an account, and the server can be set to different figures.
• Feedback you send: the reason you type when you report a visual, and the 👍 or 👎 you give an “Ask about this step” answer while signed in. Why: to find and fix wrong output.
• A one-way hash (a scrambled code that cannot be turned back into the original) of your account id, or of your network address when you are signed out, recorded against a shared question you ask. Why: to count how many different people asked it before it can be considered for the Library.
• Usage analytics, first-party. To see which pages and buttons people use and where they get stuck, the site records page views, the name of the control clicked (never what you type), how long you stayed on a page, and, from the server’s side, that a question was asked and how it was answered (its mode, subject, level and source, never its text), that an explanation, a share or a save happened, and any refusal by its error code. Your browser is given a random identifier kept in its own storage; it is not your address, not a fingerprint and not shared with anyone. When you are signed in, these events are held against your account and go with it when you delete the account. Why: to improve the product. You can turn it off with the switch at the foot of this page or in Settings → Privacy, and browsers that send Do Not Track or Global Privacy Control are treated as having turned it off.
• StudyKaKeyda does not sell your data and does not share it for advertising. The outside parties that receive anything are named in full below.

In plain words: StudyKaKeyda collects what it needs to answer your question and keep the service running, plus its own usage counts that you can switch off, and nothing for advertising.

The three ways to ask, and what leaves your device

There are three ways to give StudyKaKeyda a problem, and they behave differently. Read the one you use.

Typing a question. The text is always sent to StudyKaKeyda’s server. What happens next depends on the question. Plain arithmetic is answered by the built-in maths engine and goes no further. A question that matches a built-in template word for word is answered from that template and goes no further either. Otherwise the question is normalised (tidied into a standard form) and looked up in the shared cache. An exact match is served from there with no AI call at all. Only when nothing matches does anything reach an AI provider. First, the same question with every number masked is sent to Google’s Gemini API as an embedding request. An embedding is a numeric “shape” of the question, used to find similar ones, and embeddings only ever go to Gemini. If a matching shape comes back, your question is sent too whenever the built-in parser cannot read the numbers out of it. If no shape comes back, the question is sent as the prompt: once to classify it, again to answer it, and once more if the first answer has to be repaired. The section on third parties explains which provider receives each of those calls.

Normalised means lower-cased, with numbers and units put into a standard form. Nothing is removed or hidden, so anything personal you typed stays, in substance, in the stored copy.

Pasting code, with your program input and your entry expression. Pressing Visualize sends all three to StudyKaKeyda’s server, whatever the language. For Python, JavaScript, TypeScript and PHP the server only checks the request and hands the code straight back as the recipe for the visual. At that point it is not stored, not logged and not sent to any AI provider. The tracing then happens inside your browser, in a worker whose network access is removed before your code runs. Java, C, C++, Go and Ruby are different. The server forwards their source, your entry expression and your input, over a signed request, to a separate code-runner server. There the run happens inside a throwaway container with no network access. Nothing of your code is kept once the run finishes.

The runner’s log line records the language, the outcome, the duration and the number of bytes. It does not record your source, with one exception: when a run fails inside the runner itself, the line carries up to 2,000 characters of the tracer’s error output, which can quote the line of your code that failed.

Pasting code by itself makes no AI call and writes nothing to the shared cache. Your code is stored only if you are signed in, when the visual is saved to your history with it. Two later actions do send your code to an AI provider. Switching the language in the player sends up to 20,000 characters for translation. Asking about a step sends up to 6,000 characters of your code as context. That request also carries the step’s title, its explanation, the current values, the earlier turns of that thread, and a set of reference notes the server takes from its own knowledge_chunks table.

Giving input → output examples. Your examples and the problem statement you confirm are sent to the server and then to an AI provider. If you are signed in and you save the item, they are stored with it.

In all three modes, whatever you have typed but not yet submitted is autosaved in your own browser under the key skk.formDraft, one slot per input tab. After 7 days a slot is no longer offered back to you, but the text itself stays in your browser until it is overwritten, you sign out or you clear site data. Submitting clears only the tab you submitted, so a draft left in another tab survives.

In plain words: a typed question or a set of examples usually goes to an AI provider, though plain arithmetic and questions the built-in engine or the shared cache already answers never do; pasted Python, JavaScript, TypeScript and PHP pass through the server untouched and are traced in your browser, while Java, C, C++, Go and Ruby are run on a separate runner.

Photographs of a question

A photo is uploaded. Your browser first shrinks it and turns it into a JPEG, then sends it to StudyKaKeyda’s server inside the request. The server forwards it straight to an AI provider that can read images: Google’s Gemini API, or OpenAI’s API when the operator has added a key for it. xAI and Groq never receive photos.

StudyKaKeyda does not store the photo at all. There is no database row, no file written to disk and no log line that contains the image. It exists only for the length of that one request and is then gone. In your browser the preview is released as soon as the photo has been read. The only thing the server logs about a photo is the reason one was refused, together with your user id, or a short hash standing in for a signed-out caller.

The line “a photo of a question is read once and never stored” is true about storage. It does not mean the photo stays on your device. It does not stay on your device; it is uploaded and forwarded. What the provider does with an image after it arrives is covered in the section on third parties.

The text read out of the photo is placed into your question box, or into the code editor when the picture looks like a program. From then on it is ordinary typed input and follows the path described above for that mode: the autosaved draft, the server-side records and, for a program in Java, C, C++, Go or Ruby, the code runner.

In plain words: a photo does leave your device and goes to Google or OpenAI to be read, but StudyKaKeyda itself keeps no copy of it anywhere.

Saying a question out loud

The microphone button uses the Web Speech API, a speech-to-text feature built into the browser. StudyKaKeyda receives only the finished text. No audio is ever captured, uploaded or stored by StudyKaKeyda at any point.

Most people assume that means the audio never leaves the device. It does leave. In Chrome, Edge and Safari the Web Speech API is a network service: the browser itself streams your microphone audio to its own vendor’s speech servers, Google’s for Chrome and Edge and Apple’s for Safari. That is the browser’s behaviour, started by the button but not controlled by StudyKaKeyda, which is why dictation stops working without an internet connection. What those vendors keep is their business and cannot be checked here. Firefox does not offer the feature at all, so the button does not appear there.

Dictation stops on its own after 5 seconds of silence and stops for good after 90 seconds. Your chosen dictation language, English (India) or Hindi (India), is kept in your browser under the key skk.speechLang. It is never sent to StudyKaKeyda, though your browser passes it to its own speech service along with the audio. The microphone is allowed only for StudyKaKeyda’s own site; camera and location access are switched off.

In plain words: StudyKaKeyda never receives your audio, but your browser sends it to Google or Apple to turn it into text.

Accounts and sign-in

An account is optional. Asking questions, tracing code, reading a photo and browsing the Library all work signed out. What an account adds is your history across devices, reopening a visual at the exact step you left, and saved “Ask about this step” threads.

Sign-in is handled entirely by Supabase Auth. The methods are email with a password, an email one-time code or link, a phone number with an SMS code, and Google or Facebook sign-in where those have been switched on for the server.

Your password goes from your browser straight to Supabase over an encrypted connection. StudyKaKeyda’s API and database never see it and never store it. What Supabase does with it from there, how it is stored and how long it is kept, is Supabase’s to state and is not something this product can verify.

StudyKaKeyda’s own database does not hold your email address. Its profiles table holds your Supabase user id, an optional display name, a small block of preferences, unused columns for your level and your preferred languages, and the times the row was created and last changed. Your email address is read at the moment of each request from the signed token Supabase issues, and is not written down. Your phone number, in international format, is held by Supabase only.

If you sign in with Google or Facebook, the provider returns your id, name and email address to Supabase. Facebook sign-in is requested with the email permission. You can unlink a connected provider in Settings, as long as another way to sign in is left.

SMS codes are sent through whichever gateway is configured inside Supabase, which may well be a separate company, and that setting lives outside this product, so it cannot be named here. The same applies to the service that delivers sign-in emails.

In plain words: an account is optional, Supabase handles it, and StudyKaKeyda’s own database never holds your password or your email address.

Asking a question without an account

StudyKaKeyda’s FAQ says questions are saved to your history only when you are signed in. That is true about your history: your history is the list you see on the History page, and nothing is written to it unless you are signed in. But it would be wrong to conclude that a signed-out question leaves no trace, so this policy says it plainly: a question asked while signed out is still written to the server.

Every AI-answered question, signed in or not, leaves a server-side record, and which one depends on how it was answered. When the AI picks a template or draws a scene, the result is written to the shared cache along with the normalised question. When the AI writes code, the question goes into a generation record first and reaches the shared cache only once your browser has verified that code. A question the built-in engine answers on its own (plain arithmetic, or a question that matches a template word for word) writes nothing at all.

• A generation record. It holds your question text and the mode you used. For a signed-out caller it is keyed by a client key, a sha256 hash of your IP address joined to the first part of your browser’s user-agent string, so that only the caller who asked can verify the result. These records are deleted automatically after 7 days, and the client key goes with them.
• A shared cache row. It holds the normalised question, the same question with its numbers masked, the embedding of that masked text and the recipe for the visual. It has no owner and no reference to any user. It has no expiry and no deletion path, and it is not removed when an account is deleted.
• An asker record. When a question is answered from the shared cache, the server notes that you asked it, so that the Library can count different people rather than repeat questions. The record is a one-way hash of your account id when you are signed in, or of your network address when you are not, never the id or the address itself. Everyone behind one network address counts as one asker when signed out. Asker records are deleted after 90 days, or sooner with their cache row.
• Your raw IP address is used for the free daily AI limit. It is held only in the server process’s memory, as a key against a list of call times over a rolling 24 hours. It is never written to disk or to the database, and it is lost entirely when the process restarts. Call times older than 24 hours stop counting, and the address itself is dropped the next time a signed-out question sweeps the list, so with no such question it can sit in memory a little longer. There is no way to delete it by hand.
• A second, separate counter keyed by IP address holds requests to a fair rate over a 60-second window, also in memory. When a request is refused for going too fast, the log line records only a 16-character hash prefix of the address, never the address itself.
• The free daily AI limit is counted per IP address when you are signed out and per account when you are signed in, so everyone sharing an internet connection shares one signed-out allowance. The figures built into the software are 20 AI questions a day signed out and 100 with an account; the server can be set to different numbers, so treat these as the defaults rather than a promise.

In plain words: signing out keeps a question out of your history, but it does not keep it off the server.

Your question can become part of the public Library

This is the single most important thing in this policy.

A question can be promoted into StudyKaKeyda’s learned Library when four things are true. At least three different people have asked it. Its answer has been verified. It has never been reported. And it teaches something the built-in catalogue does not already cover. Different people means different accounts or, for signed-out students, different network addresses, counted through the asker records described above. One person asking the same question again does not count twice.

A promoted question is not public straight away. By default it waits until the operator has reviewed it and chosen to publish it. The server can instead be set to publish promotions automatically, so treat a promoted question as one that may be published after review. Once published, the Library is public: it is served to every visitor of the Learn page.

A Library entry holds the normalised question text and a hash of it, along with a title, a subject, a topic, a short summary, tags and the whole recipe for the visual. It carries no reference to you: no user id, no account link and no client key. That is good for your anonymity and bad for your control. Nothing ties the entry to you, so there is no way for you to find it and no way for you to delete it.

A Library entry has no expiry. Deleting the item from your history does not remove it. Deleting your account does not remove it.

A report from a signed-in student takes an entry off the Learn page at once, and keeps its question off the Library for good. Reports from signed-out students do the same once two different networks have reported it. Until then the server remembers only a one-way hash of each reporting network, in memory, for up to 7 days. This applies to a report on the answer the entry came from and to a report on the Library entry itself. The entry is hidden, not deleted. Its row, with the normalised question, stays in the database, and only the operator can publish it again. A report on the entry itself keeps no reason text; the server logs only which entry was reported.

Treat a question, then, as something you may be publishing. Do not put your name, your phone number, your email address, your roll number, your address, your school or employer details, or anything about another person into a question. Describe the problem and leave yourself out of it.

If you believe a Library entry contains something about you, write to support@studykakeyda.com with enough detail to identify it and it will be hidden.

In plain words: a question asked by at least three different people may be published publicly after review, with no way for you to delete it (reporting hides it, but the row stays), so leave yourself out of it.

What is stored in your browser

StudyKaKeyda sets no cookies. There is no cookie-setting code anywhere in the product, no session cookie and no cookie banner, because there is nothing on StudyKaKeyda’s own site to consent to.

What it uses instead is browser storage: localStorage, sessionStorage and the service worker’s cache. Your sign-in session lives in localStorage, not in a cookie. This storage sits on your device and StudyKaKeyda cannot read it remotely, but it is worth knowing about: several of these keys stay until you clear site data, and several have no delete control inside the app. Clearing site data for studykakeyda.com in your browser removes all of them.

Here is every key and what it holds.

• localStorage skk.auth — your Supabase session: access token, refresh token, user id, email address and phone number.
• localStorage skk.auth-code-verifier — a one-time verifier used during Google, Facebook and email-link sign-in.
• localStorage skk.devToken — a local development sign-in token. It is refused outright in production.
• localStorage skk.prefs — theme, accent colour, playback speed, reduced motion, autoplay, explanation language and whether visuals open in 2D or 3D.
• localStorage skk.accent — the accent colour, read by the small script that runs before the page paints.
• localStorage theme — light or dark, set by the theme switcher.
• localStorage skk.lang — the language AI explanations are written in: English, Hindi or Hinglish.
• localStorage skk.speechLang — your dictation language, English (India) or Hindi (India).
• localStorage skk.formDraft — your autosaved question text, pasted code, program input and input → output examples, one slot per input tab. After 7 days a slot stops being offered back to you, but the text stays in your browser until it is overwritten, you sign out or you clear site data.
• localStorage skk.visits — a count of your visits, used to decide when to offer the install banner.
• localStorage skk.installDismissed — when you last dismissed the install banner.
• localStorage skk.rail.v1 — the width of the player’s side rail.
• localStorage skk.narr.v1 — the height of the explanation panel.
• localStorage skk.code.v1 — the height of the code panel.
• localStorage skk.coach.v1 — whether you have dismissed the first-run tips.
• localStorage skk.coach3d.v1 — whether you have seen the tip on turning a 3D picture.
• localStorage skk.visitor — the random identifier the usage analytics use to tell one browser from another. Never created while analytics are off, and removed when you turn them off.
• localStorage skk.analytics — the value “off” when you have turned usage analytics off (the switch on this page or in Settings → Privacy).
• sessionStorage skk.current — the visual you have open: your request, the response, any saved ids and whether you last viewed it in 2D or 3D. It disappears when you close the tab or sign out.
• sessionStorage skk.draft — a prefill for the home form when you choose to edit and re-run. Removed when it is used or you sign out.
• sessionStorage skk.authNext — where to send you after sign-in. Restricted to paths on this site, and removed as soon as it is used.
• sessionStorage skk.visitCounted — marks this tab’s visit as already counted.
• sessionStorage skk.session — the usage-analytics session id for this tab and when it was last active; a new one starts after 30 minutes of quiet.
• sessionStorage skk.pending — the usage-analytics batch handed to the browser as you leave a page, kept until the next page has re-sent it (the server counts it once). Removed when you turn analytics off.
• sessionStorage skk.askRecent:… — the last three “Ask about this step” questions for the visual you are viewing. Removed when you close the tab or sign out.
• sessionStorage skk.authRecovery — a note that this tab has just signed in through a password-reset link or a texted code, so the reset page may set a new password without the old one. It holds the time and your user id, counts for 30 minutes at most, and is removed once the password is set or you sign out.
• Cache Storage skk-shell-… — the app’s own pages, the offline page, icons and worker scripts.
• Cache Storage skk-static-… — the app’s scripts, styles and self-hosted fonts.
• Cache Storage skk-runtime-… — the public configuration response and other public requests to this site.
• Cache Storage skk-cdn-… — the code libraries fetched from the jsDelivr CDN. This one is kept on purpose across app updates so the editor and the Python and PHP runtimes do not have to be downloaded again.

In plain words: StudyKaKeyda sets no cookies, but it does keep a list of things in your browser’s local storage, including your sign-in session.

Two limits on the “no cookies” statement

The first limit is scope. “No cookies” is a statement about StudyKaKeyda’s own site. When you sign in with Google or Facebook your browser is handed to those sites, sign-in traffic goes to Supabase, and code libraries load from cdn.jsdelivr.net. Whether those domains set cookies of their own during those exchanges cannot be determined from StudyKaKeyda’s code, and this policy does not claim otherwise.

The second limit is substance. The list above is around twenty browser storage keys, some of which stay indefinitely. Many privacy rules treat such storage the same way they treat cookies, and so should you. Nothing in it is used for tracking or advertising, but it is still storage on your device.

Two things keep personal content out of the offline cache. The service worker deliberately skips every API request except the public configuration one, so no personal response is ever cached. Every API response is also sent with a no-store instruction.

StudyKaKeyda’s own code uses no IndexedDB. The libraries loaded from the CDN (the Python runtime, the molecule drawer, the 3D molecule shape builder and the code editor) may create browser storage of their own, which is not something this policy can verify.

In plain words: “no cookies” describes StudyKaKeyda’s own site, and the storage above still deserves the same care as cookies.

What is stored on the server

The server’s only data store is a Postgres database hosted by Supabase. Your browser never queries it; only the server connects. Row-level security is switched on with no policies at all, so even a leaked public key returns nothing.

These are the records it holds.

• profiles — your Supabase user id, an optional display name, your preferences, unused columns for your level and preferred languages, and the times the row was created and last changed.
• problems — a saved item: its title, subject, tags, bookmark flag, the raw question text you saved, any input → output examples, the statement you confirmed and a share token if you created one.
• solutions — the code versions belonging to a saved item.
• runs — a table for the result of running a saved program: your program input, the program’s output, its error text, a step count and an optional pointer to a stored trace file. It belongs to your saved code, so it is account data and is listed here for completeness. Nothing in the product writes to it or reads from it today, so it stands empty, but the table exists and this policy names it rather than leaving it out.
• scenes — the visual itself and the step you last viewed.
• ai_threads and ai_messages — your “Ask about this step” questions and the answers, with the model used and token counts. These are written only when you are signed in. A signed-out question of this kind is not stored at all.
• feedback — the reason you type when you report a visual, up to 500 characters, and the 👍 or 👎 you give an “Ask about this step” answer (one per answer; a new rating replaces the old one), each stored with your user id. It is written only when you are signed in. A signed-out report of a generation is stored on that generation record instead, and a signed-out report of a cached answer is discarded without being stored anywhere.
• usage_daily — how many AI calls, embedding calls and cache hits your account made on each day.
• ai_generations — the question text of a generation awaiting verification, keyed by your user id or by the client key described above.
• viz_cache — the shared normalised question, the same question with its numbers masked, the embedding of that masked text, the recipe, a title and subject, and counts of how often it has been served and reported. No owner, no expiry.
• viz_cache_askers — one row per different asker of a shared question: the question’s cache id, a one-way hash of the asker’s account id or network address, and when they first asked. Deleted after 90 days.
• library_entries — the Library: the normalised question and a hash of it, a title, a subject, a topic, a summary, tags, the level, the whole recipe, a priority, a hit count and a status (waiting for review, published or hidden). Only published entries are shown on the Learn page. No user reference.
• ai_api_key_calls — one line per attempt to reach an AI provider: the provider, which of the operator’s keys was used, the model, the kind of task, the outcome, the HTTP status, a short error in StudyKaKeyda’s own words, the time it took and the token counts. Never the prompt, the answer or who asked. Deleted after 30 days.
• analytics_events — the usage-analytics stream: the time, the random browser identifier, the session id, your user id when you were signed in, the event (a page view, a click and the control’s name, time on a page, a question asked and how it was answered, an explanation, a share, a save, a sign-in), the page’s path, the coarse device class, browser family and operating system family, and the site you came from if any. Never the text of a question, code, an address or a name. Deleted after 30 days.
• analytics_daily — daily totals computed from that stream (views per page, clicks per control, sessions per journey, funnel counts), with no identifier of any kind. Kept indefinitely.
• knowledge_chunks — reference notes used to build visuals and to ground the answers to “Ask about this step”. This is StudyKaKeyda’s own material rather than yours, but notes retrieved from it are sent to the AI provider alongside your question.

In plain words: signed-in content lives in a Postgres database that only the server can reach, and deleting one item only hides it.

Deleting things, and what deletion does not reach

Deleting an item from your history is a soft delete. The row is marked with a deletion time and stops appearing in your history. The row itself, its code versions, its scenes and the question text saved with it stay in the database. Nothing ever purges them. No scheduled job in the product looks for rows with a deletion time set, so a soft-deleted row stays until the account is deleted. The only automatic clean-up that runs covers the seven-day generation records.

One thing a soft delete does reach, and it is in your favour. The public share lookup only returns a row with no deletion time, so a share link for an item stops opening the moment you delete that item from your history.

Deleting your account is different and goes much further. In Settings, under Data & privacy, “Delete my account” removes your profiles row and everything tied to your user id: saved items, code, scenes, AI threads, feedback, usage-analytics events and usage counters. It then asks Supabase to delete the sign-in user, which is how your email address, phone number and connected identities are meant to go.

That Supabase request has three limits you should know. It is only sent when you signed in with a real Supabase token; a session created any other way clears the local data and leaves the sign-in user alone. It is best-effort: if the request fails, the failure is written to StudyKaKeyda’s log and you are not told. And if the server’s Supabase administrative key has not been configured, the request is not sent at all. In that case only a warning is logged, and your email address and phone number would remain with Supabase. What Supabase keeps in its own records afterwards is outside this product.

Three kinds of record survive account deletion whatever happens. Shared cache rows survive, because they have no owner. Library entries survive, because they have no user column at all. Asker records survive until their 90 days are up, because they hold only a hash.

A share link is public by design. Anyone holding the link can open that visual at the chosen step. The public response gives the title, subject, level, the visual and when it was shared, and nothing about you. You can rotate the link or switch sharing off at any time, and both actions are recorded in the security log.

Two further points about where the data physically sits. StudyKaKeyda’s own documentation records the database region as Mumbai. That is a documented setting rather than something this policy can verify from the running configuration. The API itself runs on shared hosting from Hostinger, which terminates the encrypted connection and therefore sees every request. StudyKaKeyda’s own application logs are written without raw IP addresses. But the web server in front of the API and the host’s access logs sit outside StudyKaKeyda’s code, and their content and retention are not established here.

In plain words: deleting an item from history only marks the row, and deleting your account still leaves the shared cache and the Library untouched.

Third parties and what each one receives

These are the outside parties involved, and exactly what each one receives.

The AI providers. Every AI call runs on one of a pool of API keys that the operator configures on the server. Google’s Gemini API is the default. OpenAI, xAI (Grok) and Groq are used only when the operator has added keys for them. The server tries providers in an order the operator sets: by default Gemini, then OpenAI, then xAI, then Groq. It moves to the next only when an earlier one fails or is unavailable, for example because its keys are over their limits. So any one call can end up with any configured provider, and you cannot choose which.

What a provider receives depends on the call. Classifying a question, drawing a scene, repairing an answer, reading the numbers into a template, writing or translating code and answering “Ask about this step” can go to any configured provider. Between them, those calls carry: your question text; your input → output examples and confirmed statement; your source code when you ask about a step or switch the code’s language; the current step’s title, explanation and values; the earlier messages in the same thread; and the reference notes the server attaches from knowledge_chunks. A photograph goes only to a provider that reads images, Gemini or OpenAI, sent as image data inside the request. Your normalised question with its numbers masked is sent for embedding to Gemini only. Every provider receives the server’s IP address and the operator’s API key, never your IP address, because your browser never contacts an AI provider directly.

Each provider handles what it receives under its own API terms: Google’s Gemini API terms, OpenAI’s API terms, xAI’s API terms and Groq’s terms of service. What each keeps, for how long and for what purpose is its business. This policy cannot verify it or promise anything about it. One thing about Google is important enough to state plainly. There is no data-processing agreement with Google in this product, no no-training flag on the requests and no Vertex AI or enterprise Google Cloud setup. The code is written around the free tier’s quota behaviour, and Google’s published terms permit free-tier inputs to be used to improve its services. So your questions, your code and your photographs may be used by Google to improve Google’s products. Nothing in the requests to OpenAI, xAI or Groq asks them not to keep or learn from what they receive either. What can be verified is StudyKaKeyda’s own side. Request and response bodies are never logged and never written to the database, and neither are image bytes. For each attempt the server keeps a short record for 30 days: the provider and key, the model, the kind of task, the outcome, the time taken and the token counts. Never the prompt, the answer or who asked.

Supabase, for sign-in. Supabase receives your email address, your password over an encrypted connection, your phone number, and the id, name and email address returned by Google or Facebook. It issues and refreshes the session tokens your browser holds. As the party your browser connects to directly, Supabase also sees your IP address and user agent.

Supabase, for the database. The Postgres database described above. It holds everything in the server list and nothing else.

The code-runner server. A separate, self-hosted service that compiles and traces Java, C, C++, Go and Ruby. It receives your full source code, your entry expression and your program input, forwarded by the server over a signed request. Your browser never contacts it directly. Each run happens in a throwaway container with no network access, and nothing of your code is kept once the run ends. The log line records the language, the outcome, the duration and a byte count, except when a run fails inside the runner, where it also carries up to 2,000 characters of the tracer’s error output, which can quote a line of your code. The underlying server provider cannot be identified from the code.

Your browser’s speech service: Google for Chrome and Edge, Apple for Safari. It receives your microphone audio when you use dictation, and the dictation language your browser passes with it. StudyKaKeyda never receives the audio and never sees what the vendor keeps.

Google and Facebook, as sign-in providers. They receive a full-page visit from your browser when you choose “Continue with Google” or “Continue with Facebook”, and they return your id, name and email address to Supabase.

The jsDelivr CDN. It delivers five code libraries straight to your browser: the Python runtime, the PHP runtime, the molecule drawer, the 3D molecule shape builder and the code editor. None of your content is sent. What jsDelivr does receive, on every one of those loads, is your IP address, your user agent, the referring page and the path of the file requested. That path reveals which feature you opened. The Python runtime loads only when you run Python, the PHP runtime only when you run PHP, the molecule drawer only when you view a molecule, the shape builder only when you view in 3D a molecule whose shape StudyKaKeyda does not carry itself, and the editor only when you open the code tab. This is a direct connection from your browser to a company StudyKaKeyda has no agreement with. What jsDelivr logs, and how long it keeps it, are outside this product.

An SMS gateway, used only for phone sign-in. It receives your phone number and the verification code. It is configured inside Supabase rather than in this product, may well be a separate company, and cannot be named here. The same applies to the service that delivers sign-in emails.

Hostinger. The hosting provider for the API and the site, described above.

Beyond Google, whether data-processing agreements are in place with OpenAI, xAI, Groq, Supabase, Hostinger, the code-runner provider or jsDelivr is not established here. The data flows above are proven from the software; the contracts behind them are not part of it.

Two things are deliberately not on this list. Typefaces come from Google Fonts at build time only and are served from this site, so no request goes to Google when you load a page. And there is no third-party analytics or telemetry service of any kind: the site’s own usage counts, described above, stay on its own server.

In plain words: an AI provider (Google’s Gemini by default, or OpenAI, xAI or Groq where the operator has added them) sees your questions and the code you ask about, only Gemini or OpenAI see photos, Supabase holds your account, a separate runner sees compiled-language code, and your browser’s vendor hears your voice.

How long things are kept

Different records are kept for very different lengths of time, so they are listed one by one.

• A photograph — the length of one request. Nothing is kept.
• Source code sent to the code runner — the length of one run, and nothing of it is kept afterwards.
• Your raw IP address for the daily AI limit — up to 24 hours of call times in server memory, lost on restart, never written down. The address itself is dropped the next time a signed-out question sweeps the list.
• The per-IP rate-limit counter — 60 seconds in server memory.
• Generation records, including the client key and any anonymous report text — deleted after 7 days by a scheduled job.
• Asker records, the one-way hash of your account id or network address held against a shared question — deleted after 90 days by a scheduled job, or sooner with their cache row.
• Records of each attempt to reach an AI provider, which hold no prompt, answer or user — deleted after 30 days by a scheduled job.
• Usage-analytics events — deleted after 30 days by a scheduled job (the server can be configured with a different figure), or at once with your account. The daily totals computed from them carry no identifier and are kept indefinitely.
• A signed-out report of a cached answer — not kept at all. The reason you typed is discarded without being written anywhere.
• Your unsent draft in the browser — the slot stops being offered back after 7 days, but the text stays until it is overwritten, you sign out or you clear site data.
• The visual you have open, held in the browser — until you close the tab or sign out.
• Saved items, code, scenes, AI threads, feedback and usage counters — for as long as your account exists. Deleting an item soft-deletes it, as described above, and no job ever purges a soft-deleted row; only account deletion removes these rows.
• Shared cache rows holding your normalised question — indefinitely. No expiry, no deletion route, not removed by account deletion, and not removed by reporting the answer.
• Library entries — indefinitely. No expiry, no user-facing delete and not removed by account deletion. A report takes an entry off the Learn page at once, but the hidden row stays in the database.
• Browser storage keys — until you clear site data for this site. Several have no delete control inside the app.
• Cached app files in your browser — old versions are pruned when the app updates; the CDN cache is kept across updates until you clear site data.
• What Supabase keeps after a sign-in user is deleted (its own audit logs, email and SMS delivery records and token history) is Supabase’s retention, not StudyKaKeyda’s, and is not established here.

In plain words: some things expire in minutes or days, your account data lasts until you delete it, and two kinds of question record last forever.

Your rights under the DPDP Act and how to use each one

Under the DPDP Act you have a set of rights over your personal data. Here is each one and the actual way to use it.

The right to know what is held and who it went to. The categories, the records and the recipients are set out in full above. For anything beyond that list, write to support@studykakeyda.com.

There is no data-export feature in StudyKaKeyda: no endpoint, no button and no file you can download. So a request for a complete copy of your data, or to move it elsewhere, has no technical path today. It would have to be put together by hand from the records listed above. This policy says that rather than implying an export feature exists.

The right to correction and completion. Your display name and your preferences can be edited in Settings. Your email address, phone number and connected sign-in providers are managed through Supabase from the same place. If something else is wrong, write to support@studykakeyda.com.

The right to erasure. Deleting one item is on the History page, not in Settings. It is a soft delete: the row is marked, not erased, and nothing purges it later. Deleting your account is in Settings under Data & privacy, behind a typed confirmation, and it removes everything tied to your user id. The exceptions are the shared cache and the Library, for the reasons given above, and the asker records, which run out after 90 days. To have a Library entry hidden, open it and report it, or write to support@studykakeyda.com with enough detail to identify it.

Reporting is not a way to erase, and should not be mistaken for one. A report on an answer increases a counter on the shared cache row so that row stops being matched. A report on the answer or on its Library entry takes that entry off the Learn page at once. But the cache row, the Library row and the normalised question text all stay in the database.

The right to grievance redressal. Send your grievance to support@studykakeyda.com. It goes to one person, who will answer it. If you are not satisfied with the outcome, the DPDP Act allows you to take the matter to the Data Protection Board of India.

The right of nomination. The DPDP Act lets you nominate someone to exercise your rights if you die or become unable to act. There is no control for this in the app; write to support@studykakeyda.com to record a nomination.

One honest limitation. StudyKaKeyda does not currently show a consent banner and keeps no record of consent, so there is no stored consent for you to withdraw in the app. The practical equivalents are to stop using the AI features, which are the only paths that send content off your device, and to delete your account.

In plain words: you can see, correct and delete your account data, some of it in Settings and the rest by email, but there is no export feature, and the shared cache and the Library are outside that reach.

Children, parents and guardians

StudyKaKeyda is made for learners of every age, from Class 4 upward, so many of the people who use it are under eighteen. The explanations use short words, and the Library has visuals for the youngest students, such as adding numbers, subtraction with borrowing and fractions.

The DPDP Act treats everyone under eighteen as a child. Section 9 of the Act requires a parent’s or guardian’s verifiable consent before a child’s personal data is processed, and it forbids tracking, behavioural monitoring and targeted advertising directed at children. StudyKaKeyda shows no advertising of any kind and sells no data. It does keep its own usage counts, described above, which a parent can switch off on this page or in Settings → Privacy.

There is no age gate, no minimum-age check and no parental-consent step anywhere in sign-up today. This policy says that plainly rather than implying a protection that does not exist. Until that changes, the site relies on families: if you are under eighteen, use StudyKaKeyda with the agreement of a parent or guardian, and ask them before making an account.

Three practical rules for a child using the site, and for the adult helping. Do not type a name, a school, a phone number, an address or anything about another person into a question, because a question can reach an outside AI provider and, once enough people ask it, the public Library. Use the site signed out unless history across devices is needed; signed out, nothing is written to a history and no account exists. And keep the switch for usage analytics off if you prefer that nothing about the child’s use is counted.

A parent or guardian who wants a child’s account and data removed can write to support@studykakeyda.com, with the email address or phone number the child signed in with. The account can also be deleted from Settings → Data & privacy.

In plain words: the site is made for students of every age but has no age check, so under-18s should use it with a parent’s or guardian’s agreement, put nothing identifying into a question, and a parent can ask for a child’s data to be removed.

How StudyKaKeyda protects what it holds

Traffic between your browser and the server is encrypted. Your password never reaches StudyKaKeyda’s server or database; it goes from your browser to Supabase, and what Supabase does with it from there is Supabase’s to state.

Logging is written to avoid personal content. The AI providers’ API keys are held on the server only and are never logged. Request and response bodies to and from AI providers are never logged or stored. Image bytes are never logged. Security log lines about refused or throttled requests carry a short hash of the IP address rather than the address.

The database is closed to the outside. Row-level security is enabled with no policies on every table, so the public data interface returns nothing even if a key were to leak, and the browser never queries tables directly. Only the server’s own connection does.

The pages are locked down as well, with two gaps worth naming rather than glossing over. A content security policy limits where the browser may send anything: this site, Supabase and the code CDN. The script rule names each of the app’s own inline scripts by hash. But if no hashes are available when the server boots, or the override setting is switched on, it falls back to allowing any inline script, which is a much weaker rule. The image rule allows an image from any https address. The microphone is allowed only for this site, camera and location are switched off, and every API response carries a no-store instruction so it is not cached.

Code you run is isolated. In-browser workers have their network, storage and cookie features replaced with stubs that fail before your code starts, so they cannot reach the page, its storage or the network. On the code runner, each run is a throwaway container with no network access at all.

No system is completely secure, and this one is run by a single person. If you find a security problem, please report it to support@studykakeyda.com rather than posting it publicly.

In plain words: passwords and API keys never touch StudyKaKeyda’s logs, the database is closed to the browser, and code you run is locked away from everything else.

Changes to this policy

This policy will change when the product changes. The current version was last updated on 26 September 2026, and that date is the way to tell whether you are looking at something new. The terms of use are a separate document at /terms and change on their own schedule.

When a change is material (a new recipient of your data, a new category collected or a change in how long something is kept) the updated policy will be published at /privacy before or at the time the change takes effect. There is no mailing list, so the page itself is the notice.

Continuing to use StudyKaKeyda after a change means the current version applies to you. If a change is one you are not comfortable with, you can delete your account in Settings.

In plain words: changes show up as a new date at the top of this page, so check it now and then.

Contact

For anything in this policy (a question, a correction, an erasure request, a grievance, a nomination or a security report) write to support@studykakeyda.com.

StudyKaKeyda is run by one person, not a company, so there is no support desk, no registered office and no separate data protection officer. Replies come from that one person. Please allow a reasonable time, and include enough detail for the request to be acted on: for an account request, the email address or phone number you signed in with; for a Library entry, the wording of the question.

If you are not satisfied with how a grievance is handled, the DPDP Act allows you to approach the Data Protection Board of India.

In plain words: one email address reaches the one person who runs this, and it is the route for every request in this policy.