Privacy Policy

Last updated: November 10, 2026.

This policy describes what Classla LLC ("Classla", "we", "us") collects through https://classla.org, https://app.classla.org, and the software and services offered there (the "Service"), what we do with it, and who else sees it.

Classla is used by K-12 classrooms. We have written this to be read by a teacher or a district reviewer, so it describes what the product actually does rather than what a generic software company might do.

The Short Version

• A student account needs a username and a password. Nothing else. No email address, no real name, no date of birth.
• Student work belongs to the student and their school. It is not ours.
• We do not sell your data. We do not show ads and we do not use your data to target them. We run no analytics, no tracking pixels, and no third-party cookies, and we have no email marketing system.
• You can ask for a copy of your data, or ask us to delete it, at any time.
• If we ever have a breach, we tell affected customers within five business days.

Students, Schools, and Parents

Student accounts are created and controlled by the school. A teacher or school administrator creates each account, chooses what information goes into it, and can change or remove it. Where a school has connected its learning management system, an account can also be created from the school's LMS roster, with the name the LMS holds (see "Your School's Learning Management System" below). In doing so the school acts as the agent of the student's parent or guardian in authorizing the student's use of the Service. We collect only the information the school gives us. There is no age minimum for a school-created student account, and we never ask a student their age.

We use student data only to provide the Service to the school and under the school's direction. We do not use it to build profiles for anything other than the student's own education, and we do not use it for any commercial purpose.

For education records, Classla acts as a school official with a legitimate educational interest under 34 CFR 99.31(a)(1)(i)(B), under the school's direct control. We will sign a school district's data privacy agreement setting that out.

A parent who wants to see, correct, or delete their child's information should ask their child's school, which can act on it directly in the product or ask us. A school may also contact us at camden@classla.org to stop any further collection about a student.

The self-service sign-up at app.classla.org is for teachers and other adults setting up a class.

What We Collect

Teacher and administrator accounts. Email address, first and last name, and a password, handled by our identity provider (see the vendor list below). We use these to sign you in and to contact you about your account.

Student accounts created by a teacher. A username and a password hash. First and last name are optional. There is no email address on a student account. What identifies a student in Classla is whatever their teacher chose to type. An account created when someone opens Classla from their school's learning management system is described under "Your School's Learning Management System" below.

Coursework. Assignments, submissions, answers, grades, feedback, files in the in-browser IDE and their version history, test and program runs, notes, attendance records, and uploaded photos of handwritten work.

Time and activity. Classla records how long a student actively spends on each question, on each assignment page, and in the coding editor, when a student opens a course or an assignment, and which students opened each file in a course's Files library. In group work it also records each member's share of the typing and of the time. Only course staff see these. Students never see time or activity records, not even their own.

Editing and integrity records. Classla records the edit history of a student's files, and it records pastes into the coding editor, including the pasted text, so that a teacher can see where code came from. A teacher chooses per assignment whether pasting from outside is blocked or simply recorded. Staff edits into a student's file are labeled as staff edits. When a teacher turns on lockdown for an assignment, Classla records each time a student leaves the assignment and returns. When a teacher asks for it, Classla compares the code students in a class wrote for the same coding block, on Classla's own servers, and shows the teacher which pairs are similar.

Assistant conversations. A teacher's conversations with the AI assistant are stored so the teacher can reopen them. For each model call we also keep a usage record (the model, the size of the request, the time it took, and its cost) that does not contain the text.

Bug reports. Anyone signed in can report a problem from the app. A report holds what the person wrote, the page they were on, the course and assignment if any, recent browser errors and failed requests, and a screenshot if they attach one.

Contact form. If you write to us through the public site: your name, email address, organization, role, an approximate number of students, your message, and the IP address and browser the form was sent from.

Server and error logs. Ordinary web-server records: IP address, browser and device type, timestamps, and page URLs. Operational logs identify people by an internal account id, not by email address; a check in our build fails it if a new log line carries an email address. Our internal alerts do the same, except for the few listed under Discord below.

Session recording for error monitoring. Every coding session is recorded to our error-monitoring vendor, as are one in ten other sessions and any session that hits an error, so we can reconstruct a problem a teacher or student reports. Text and form inputs are masked in those recordings, so a student's code is not transmitted as readable characters; what the recording does contain is the page layout, the internal account id, the username, page URLs, file names inside the workspace, and the browser's warning and error messages.

Cookies

Classla sets one session cookie to keep you signed in. The only others are short-lived security cookies set while you sign in with Google or another provider, or open Classla from your school's LMS, which tie that sign-in to your browser and expire within 30 minutes. There are no ad cookies, no third-party cookies, no tracking pixels, and no analytics scripts anywhere in the product or on this website. Our Service does not respond to Do Not Track signals, because there is nothing for it to turn off.

A teacher can place a video or page from another site in an assignment, such as a YouTube video. That content is served by the other site under its own policy. Classla plays YouTube videos through YouTube's privacy-enhanced mode, but YouTube decides whether a video shows ads.

How We Use Information

• To run the Service: to store and display work, run and grade code, and show a teacher their class.
• To administer accounts and to respond to support requests.
• To keep the Service secure and to investigate abuse.
• To fix problems, using error reports and session recordings.
• To contact you about your account or about a change to the Service.

We do not sell data, we do not show ads or use data to target them, we do not do market research on your data, and we do not use student data to train any model.

Who Else Sees It

We use a small number of vendors to run the Service. They receive only what they need, they may not use it for their own purposes, and they may not sell it. Below is the current list, in full.

• Amazon Web Services: application hosting, file storage, session cache, and logs, in Ohio (us-east-2). The public website and the app's static files are served from N. Virginia (us-east-1).
• Supabase: hosts the application database, in Ohio (us-east-2), including the teacher assistant's course memory and the search index of Classla's public help docs.
• Fly.io (United States): runs the machines in which student code executes, in Ashburn, Virginia. Each coding session gets its own machine.
• Google Cloud Vertex AI (Gemini models): the model behind Classla's built-in AI features, all of which are for teachers. It receives the prompts a teacher sends the assistant, which can include a student's name and their source code when a teacher asks about that student's work; and the text of a question a teacher asks the help docs (see "Asking the Docs" below).
• Google Classroom API: used only when a teacher chooses to connect their Google account to a Classla course. Classla asks Google for three Classroom scopes (classroom.courses.readonly, classroom.coursework.students, and classroom.topics) and the basic sign-in scopes openid and profile, which give the teacher's Google account id and name; it never asks for an email address. For each assignment it posts, Classla sends Google the assignment title, the due date, a message the teacher writes and can edit, one link card back to the assignment in Classla, and the name of a Classroom topic taken from the assignment's main tag. It reads the connected teacher's list of active Classroom courses and, in a linked course, that course's topics and the posts Classla itself made there; if a teacher changes a post's topic in Classroom, Classla tags the assignment to match. It stores an encrypted refresh token, the Google account id and display name, and Classroom course, coursework, and topic ids. It sends no student data to Google: no names, no usernames, no work, no scores. It does not read rosters, student profiles, or grades, and grades do not push to Classroom. Disconnecting revokes Classla's access at Google and deletes the stored token, and the teacher can choose to remove Classla's posts from Classroom at the same time. The client ID and the steps a Workspace administrator takes to allow it are on Classla and Google Classroom for Workspace admins. Classla's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
• Sentry (United States): error monitoring and the session recordings described above.
• WorkOS (United States): sign-in for teacher and administrator accounts: email, name, and password. Student accounts created by a teacher, and accounts created through an LMS, never reach WorkOS.
• Discord (United States): our operational alert channel. It receives error notifications, messages sent through the contact form, the text of in-app bug reports with the reporter's email address but never their name, the email address of a teacher who asks to be verified, and each message a teacher sends the assistant, with that teacher's email address, shortened to fit. If someone links their Discord account to their Classla account from our Discord support server, our support bot can look up their name and the email address on their account.
• Tavily: runs a web search when a teacher asks the assistant to search. It receives the search text only.
• Jina Reader: fetches a web page when a teacher asks the assistant to read one. It receives the URL only.

Two things worth stating plainly, because a district will ask:

• Students cannot use the AI assistant. It is available to instructors and teaching assistants only, and it is off by default on a new account. But when a teacher asks the assistant about a student's work, that work is part of the question and is sent to the model provider.
• Student code executes in Virginia. What reaches those machines is a workspace identifier, an internal account id, and the files themselves; no name or email address travels with them, and re-identification requires our database in Ohio.

Connected AI Apps

A verified teacher can connect Classla to an AI app they already use, such as Claude, ChatGPT or Gemini. Once connected, the app reads and changes the courses the teacher teaches, as the teacher, within the permissions the teacher chose on Classla's connect screen. Student accounts cannot connect an app.

What a connected app can receive. Classla answers each request the app makes with what that request needs, and only within the permissions the teacher granted:

• Read your courses and assignments (on unless the teacher unticks it):
  • The teacher's courses: each course's name, join code and link, the teacher's own role in it (instructor or teaching assistant), and whether it is archived.
  • Sections: their names and how many students each has. Counts only, no names.
  • Assignments: titles, folders, every question with its answer key, model solutions, starter code, autograder tests and their results on that code, rubrics, settings and due dates, and how many students have their own due date. A count only, no names.
  • Course setup: tags, the Files library (file names, types and sizes), the course's Summary page, grading scheme and defaults, and the Google Classroom posting status of each assignment, by Classroom course name.
  • Notes the teacher's Classla assistant saved about the course. These can mention a student if the teacher wrote them that way.
  • Classla's public help docs.
• Create and edit assignments (on unless the teacher unticks it): the changes the app asks for. Classla answers with what changed and with counts, such as how many students a due date change reached. It cannot publish an assignment, enter grades, delete an assignment, or change who is enrolled.
• Read student work (off unless the teacher turns it on):
  • Students' names as they appear in the course (the teacher's display name for a student, when one is set), their section, and their partner groups. The app refers to each student by a number (#1, #2, and so on) that Classla assigns for that connection.
  • Submissions: status, submission time, attempts, whether they were late, scores and question scores, the teacher's feedback, every answer and file of code, the output of the student's code under the autograder tests, and the random values a math question generated for that student.
  • Class analytics: each student's course grade, missing and late work, standing (on track, watch, or needs support) and its reasons, including attendance below 80%, minutes spent, when the student was last active, and how active they were each day over the last two weeks. Also the teacher's own private note on a student.
  • Integrity records: pastes from outside the editor (when, where, how many lines, and the pasted text), code similarity between pairs of students with the matching code and the teacher's review of it, and when a student left a lockdown assignment.
  • Poll responses and live game results by student, including short answers.
  • Example submissions the teacher saved, with the student's name removed.

Classla does not send a connected app anyone's email address, password, username, IP address or device, and it does not send the internal account ids that identify a person, except where a teacher typed such details into their own course content. The app also receives a few reference numbers it needs for a follow-up request in the same conversation, such as the id of a similarity pair, a saved example, a test run, a live game session, or a course's link to Google Classroom. They point to that record, not to a person.

Where it goes. What a connected app reads is sent to the company that runs it (Anthropic for Claude, OpenAI for ChatGPT, Google for Gemini), on the teacher's own account with that company and under the teacher's agreement with it. For these connections those companies are not Classla's vendors (Classla's own use of Google Cloud Vertex AI, listed above, is separate), and this policy does not govern what they do with it. A teacher should turn on Read student work only where their school allows student work to be shared with that company.

What Classla keeps. Classla runs no AI model for these connections and never receives the conversation, only each request the app makes. We keep a record of each connection (the app's name, the permissions, and when it was connected and last used) and of each tool call it makes (the connection, the tool, the course and assignment it named, whether it worked, how long it took, and when), so that we can see how teachers use connected apps and fix problems. Neither record holds the text of a request or of Classla's answer. Our server logs also note which tool a connection called and when.

Your controls. A teacher chooses the permissions when connecting, and can change them or disconnect at any time from their account Settings, under Connected apps. A change takes effect on the app's next request, and disconnecting takes effect immediately.

Your School's Learning Management System

A school can add Classla to its learning management system (LMS), such as Canvas or Moodle, through the LTI 1.3 standard. The school's LMS administrator installs Classla, and a teacher links an LMS course to one Classla course. None of this happens unless the school sets it up.

What Classla receives from the LMS.

• When someone opens Classla from the LMS: their LMS user id, their name, their role in the LMS course (instructor, teaching assistant, or learner), and the LMS course's id and title.
• The roster of a linked course, from the LMS's roster service: each member's LMS user id, name, and role. Classla reads it when the course is linked, when the teacher asks, and every six hours. It enrolls learners who already use Classla from that LMS; anyone else stays on a list, with no account made for them, until they open Classla from the LMS themselves. Nobody is removed from a Classla course because the LMS dropped them.
• Classla does not ask the LMS for email addresses. If an LMS sends one anyway, Classla does not store it and never uses it to find or match an account.

Accounts. The first time someone opens Classla from the LMS, they either connect the Classla account they already have or start a new one. A new account has no password and no real email address; it holds the name the LMS sent, linked to the LMS user id. Where a class already has students the teacher created, the teacher matches each LMS learner to one of them; Classla never guesses a match.

What Classla sends to the LMS.

• When a teacher adds Classla assignments to the LMS: each assignment's title, its point value, and a link to it.
• Scores, every 15 minutes and whenever the teacher asks: each connected student's score on each linked assignment, and only a score that student can already see in Classla. Unreleased scores, scores waiting on manual grading, and practice scores are never sent, and neither is the course total. Classla reads nothing back from the LMS gradebook.

Keys. Classla signs what it sends with a private key kept in AWS Secrets Manager, and it checks every launch against the public keys the LMS publishes. The short-lived access tokens Classla uses to call the LMS are held only in memory. Classla never holds a password for the LMS.

Undoing a connection. A teacher can unlink an LMS course in the Classla course's Settings: roster and score syncing stop at once, and the students and their work stay in the Classla course. Scores already sent stay in the LMS gradebook. The school's LMS administrator can remove Classla from the LMS at any time, and we can turn off a school's registration at its request. A person whose Classla account is connected to the wrong LMS account can write to us to have that connection removed; the next launch then asks them again.

Asking the Docs

Teachers can ask a question about how Classla works with Ask in the app header. The question is sent to Google (above) to search Classla's public help docs and to write an answer from them. Classla does not log or store the question text. Ask is hidden from students created by a teacher and from students inside their courses. Any account that is not a verified teacher, which includes every student account, gets links to the matching docs pages, and no answer is written for it.

Beyond this list, we share information only where you ask us to, where we must to comply with the law or protect someone's rights or safety, or in the event of a merger, sale, or other transfer of our business, in which case the successor is bound by this policy.

Where the Data Lives

We are based in the United States and the Service is operated from the United States. The vendors that host and run the Service (AWS, Supabase and Fly.io, above) operate it in the United States. If you use the Service from outside the United States, you are consenting to your information being transferred to and processed in the countries listed above, whose data protection rules may differ from your own.

If you are in the European Union, the United Kingdom, Liechtenstein, Norway, Iceland, or Switzerland, you may have rights over your personal data under the GDPR. We process personal data with your consent where applicable, to perform a contract with a customer, and for our legitimate interest in operating and securing the Service.

How Long We Keep It

• Student work, submissions, grades, edit history, and paste records are kept for as long as the school's course exists, so a teacher keeps the record of their class. They are removed on request.
• Every version of a student's file is kept for as long as the course exists. Nothing about a student's editing history is deleted on a timer.
• Records of when a student opened a course or an assignment are deleted after 180 days. Time spent on questions, pages, and code is kept with the course, like the work itself.
• Server logs are kept for one month.
• Sign-in sessions expire within 24 hours.
• Connected AI apps: a connection is kept until the teacher disconnects it. Its access tokens expire after one hour and its refresh tokens after 90 days, and Classla stores only a one-way hash of each. The record of each tool call is kept with the teacher's account, after a disconnect too, and is deleted when the account's data is deleted. Server logs of tool calls are kept for one month.
• Error reports and session recordings are kept for our error-monitoring vendor's standard retention period.

We are writing a fuller retention schedule with a fixed period for every category; ask us and we will tell you where it stands.

Managing Your Information

You can ask for a copy of your data, or ask us to delete it, at any time. A school or an account holder writes to camden@classla.org and we act on it. A parent should ask their child's school, which can make the request on their behalf.

Teachers and administrators can also view and correct much of this directly in the product, and can edit or remove a student account themselves.

Deleting an account is not the same as deleting data. Deleting an account removes that person's login and their access to Classla. A teacher often still needs the record of a student's work in a course after that student's account is gone, so the work stays with the course. Deleting the data itself is a separate request, and we act on it when the school or the account holder asks.

If you would rather not accept cookies, most browsers let you refuse or delete them. Refusing our session cookie means you cannot stay signed in.

How We Secure Information

We implement appropriate technical and organizational measures to protect the information we collect and store. Traffic to Classla is encrypted in transit. Passwords are stored hashed, never in readable form. Access to production systems is limited to Classla staff who need it.

No security measures are foolproof, and no network or system, including ours, can be guaranteed secure against destruction, loss, alteration, or unauthorized access. If you believe your information may not be secure for any reason, contact us immediately at camden@classla.org.

Incident Management and Response

We have a standardized process for responding to security incidents. When a security incident is suspected, our team is notified through a paging service and a central communication channel is established. After each incident, we conduct a post-mortem analysis to identify root causes and track any related follow-up work.

If we believe that a customer's personal information has been accessed or modified by an unauthorized third party, we will take all necessary steps to notify the affected customers as quickly as possible, and in no case greater than five (5) business days after we learn of the breach.

One of the first steps during a security incident is to verify that the attacker is completely out of the systems in question, or that their impacts are minimized. The second step is to identify the extent of the data breach, which should result in a list of the affected customers and data. In the event of a large data breach, we will coordinate with additional legal and security resources to assist our efforts.

In our communications with affected customers, we will include the following information:

• The nature of how the information was accessed (viewed, modified, etc)
• The actual information accessed
• What we've done to mitigate the access
• What corrective actions we will take to prevent future breaches

If you have any questions about our security program, email camden@classla.org.

Changes to This Policy

Information we collect is subject to the policy in effect when it was collected. We may revise this policy. If a revision is material we will notify you at the email address you gave us and post the amended policy here; the current version is always on this page.

If you have any questions about this Privacy Policy, contact us at camden@classla.org. Camden answers this himself.