Back to OneSnappi

Privacy policy

What this service collects, who can see it, and what has not been decided yet.

Last updated October 2, 2026

Who operates OneSnappi

OneSnappi is operated by OneSnappi LLC, a New Jersey limited liability company.

This policy covers this service only. It does not cover your school’s other systems, and it does not cover the scholarship committees your school sends applications to.

Your school decides, not us

We hold and process this information at the direction of the school that engaged us. The school decides who is a counselor, which scholarships exist, what criteria those scholarships have, and which optional profile fields appear on a generated application.

We do not make those decisions and we do not use the information for our own purposes.

What we collect

From students:

  • Name and the email address used to sign in
  • Graduation year, GPA and the scale it is recorded on, town
  • SAT total and ACT composite, both optional
  • Intended major, intended college or program, enrollment plan
  • Activities, positions and descriptions, and awards and honors
  • Phone, a personal email address, and a home mailing address
  • Essays written in the app
  • Uploaded transcript files
  • Uploaded resume files
  • Answers to the eligibility questions a counselor has written for that school’s scholarships
  • Which scholarships a student has saved, applied to, and marked as sent
  • Optionally, first-generation status, financial need, military family, gender, and race or ethnicity

From counselors: name, the email address used to sign in, and the records they create, which are the scholarships, criteria, essay prompts, announcements and award entries for their school.

The service also records things nobody types. They are kept because the product needs them to work, and they are listed separately because they are not answers a student gave about themselves:

  • Whether a student opened an announcement from their school, and when
  • Which announcements were addressed to which students
  • Which deadline reminders a student has dismissed
  • Notifications generated for a student, and whether each is still unread
  • Failed attempts to enter a school code, counted per account so that guessing can be limited. The code that was typed is never stored.

One record is written about a student by somebody else. When a counselor logs a scholarship winner, that entry can name the student, the amount, the date the award was made, and a free text note the counselor writes. A student does not enter it and does not see it.

Who can see it

A student can see everything in their own account. Counselors at that student’s school can see everything a student enters except essay text the student has hidden, and hiding is unavailable on scholarships the school marked as requiring review.

We can see it, because we operate the database. Nobody outside your school sees anything unless a student generates an application and sends it themselves.

There is also an internal operator screen, reachable only by a short list of accounts we control. It shows every school’s name and that school’s two signup codes, and it can create a school or reissue those codes. It does not read student records.

Row-level security is enabled on every table that holds school data, scoping every read to a single school. The isolation this provides has been tested directly: a real account from one school attempting to reach another school’s records is refused, rather than only reviewed on paper.

Gender and race or ethnicity

Both are optional. Leaving either blank, or choosing not to say, never affects whether a student is shown as eligible for anything.

A counselor chooses, for each scholarship separately, whether these appear on the application document a student generates. When a counselor has turned one on, the row appears on that document whether or not the student answered, and an unanswered one reads as not provided.

That document goes to the scholarship committee, which is outside the school. We have no relationship with those committees and cannot recall a document once a student has sent it.

Transcripts

A student can upload a transcript as a PDF, up to 5 MB. It is stored in a private bucket, and the links that open it expire one hour after the page is loaded.

Uploading a new transcript does not remove an earlier one. A student can delete any version they have uploaded, current or earlier, and deleting is permanent: the file is removed from storage rather than hidden, and no copy is kept. Transcripts are also removed when a counselor purges the account.

A transcript can leave the school in two ways, and both attach it only when the scholarship asked for one. First, inside the application document a student generates and delivers themselves. Second, a counselor can choose to include transcripts when she downloads the completed applications for a scholarship, to pass them on to the committee. Every scholarship carries a list of required materials entered by a counselor, and a transcript travels only for the scholarships whose list includes it. A student who has uploaded a transcript and applies to an award that did not ask for one gets a document without it, and the counselor download for that award carries no transcript either.

The student is told at the moment it happens. On the page where the document is downloaded, and only when a transcript will actually be attached, the page says that the transcript is included in the PDF and goes to the scholarship committee with it.

We do not send it. A person downloads the document and delivers it themselves, the student for their own application or the counselor for the completed set.

The copy inside a generated document does not expire. The one hour above applies to the links that open a transcript inside this service. A PDF a student has downloaded is an ordinary file: once it has been delivered, nothing here can reach it and we cannot recall it.

Resumes

A student can upload a resume as a PDF, up to 5 MB. It is stored in a private bucket, separate from transcripts, and the links that open it expire one hour after the page is loaded.

Uploading a new resume does not remove an earlier one. A student can delete any version they have uploaded, current or earlier, and deleting is permanent: the file is removed from storage rather than hidden, and no copy is kept. Resumes are also removed when a counselor purges the account.

A counselor sets, for each scholarship, whether it asks for a resume at all, and if so whether providing one is required or optional. A resume leaves the school the same two ways a transcript does: inside the application document a student generates and delivers themselves, or inside the completed set a counselor downloads to pass on to the committee. When a scholarship requires a resume, it is included whenever the student has uploaded one. When a scholarship only asks for a resume optionally, the student chooses, on the page where they review their application, whether their resume is included; that choice is saved and is what the counselor’s download honors for that student, whether or not other students applying to the same scholarship made the same choice. A resume never travels to a scholarship that did not ask for one.

The student is told at the moment it happens. On the page where the document is downloaded, the page says whether a resume is included and, when a scholarship only asks for one optionally, lets the student change that before downloading.

We do not send it. A person downloads the document and delivers it themselves, the student for their own application or the counselor for the completed set.

The copy inside a generated document does not expire. The one hour above applies to the links that open a resume inside this service. A PDF a student has downloaded is an ordinary file: once it has been delivered, nothing here can reach it and we cannot recall it.

What we do not do

We do not advertise. We do not sell or share this information. We do not build profiles for any purpose other than running this service, and we do not use it for anything the school did not engage us for.

There are no analytics, no tracking pixels and no third-party scripts of any kind in this product. That is verifiable in the source rather than a promise about intent.

Who else processes it

  • Supabase holds the database, the accounts and passwords, and uploaded transcripts and resumes.
  • Vercel hosts the application and serves every page.
  • Anthropic receives the eligibility paragraph a counselor pastes when creating a scholarship, so it can be turned into a list of criteria the counselor then reviews. It also receives the school’s GPA scale, which is a school setting rather than anything about a student. No student information is sent to it.

Security

Stated narrowly, because only what can be confirmed is listed:

  • Traffic between a browser and this service is encrypted in transit.
  • Access is scoped in the database by row-level security rather than by the page that renders it.
  • The administrative tools we use to remove an account, and the internal operator screen above, run with those database restrictions bypassed. That is how they work and it is stated here rather than left to be assumed.
  • Transcripts and resumes are each in their own private bucket and are reached by links that expire.
  • Passwords are handled by Supabase’s authentication service. This application never sees or stores one.

Nothing beyond that is claimed.

Backups

There are none. The production database runs on Supabase’s free tier with no backups configured. If it were lost, the information in it would be lost.

Where the data is stored

The database and the uploaded transcript and resume files are held in Amazon Web Services’ US East region, in Northern Virginia, in the United States. That is the region the Supabase project behind this service runs in.

The application’s own pages are served from wherever is closest to the reader, which is ordinary hosting and says nothing about where the information above is kept.

Encryption at rest

This is not claimed here.

Anything we could look up about encryption at rest would be the hosting provider’s description of its own infrastructure, and repeating it on this page would make their representation ours. We have not verified it for this project, so we do not state it.

Encryption in transit, above, is different. It is a property of this service that can be confirmed from outside it, which is why it is stated and this is not.

How long we keep it

There is no automatic deletion schedule. We keep a student’s information for as long as their account exists, which is for as long as the school keeps it. Nothing is removed after graduation or after a scholarship season ends on its own.

Retention ends when the school acts: a counselor can remove an individual student’s account at any time (see Deletion below), and a school can end its use of the service entirely, which removes its data. Until either happens, information is kept.

Deletion

A counselor at the school can remove a student account. Doing so deletes the profile, essays, applications, and uploaded transcripts and resumes.

A student can delete their own uploaded transcripts and resumes at any time, described under Transcripts and Resumes above. That is the only part of their information a student can remove themselves. There is no way for a student to delete their own account, and no way for a student to export their own information.

Everything else is requested through the school. We hold this information at the school’s direction, so we act on the school’s instruction rather than on a request from a student directly, and the school decides. Deletion happens at the school’s direction, not on a schedule we set.

If a student cannot reach anyone at their school, they can write to onesnappi.school@gmail.com. What we will do is pass the request to the school. We will not act on it ourselves: we have no way to confirm who is asking, and the decision belongs to the school. We do not promise a timeframe, and we do not promise that anything will be deleted.

If something goes wrong

If we learn that information in this service has been exposed, we will tell the affected people and their school. We have not set a timeframe for that notice, so none is promised here.

To report a security concern, or to ask about anything on this page, write to onesnappi.school@gmail.com.

Minimum age

Accounts are for high school students, and a student must be at least 13 to create one. We do not ask for a date of birth, so this is a condition of using the service rather than something the software checks.

There is no parental consent step in this product.

What this policy does not claim

None of the following has been established, and this page should not be read as asserting any of them: compliance with FERPA, compliance with any state student privacy statute, SOC 2 or any other certification, or any completed third-party audit.

They are listed because silence about them is easy to misread as compliance, and because a district reviewing this service should be able to see what has not been done as clearly as what has.

Changes to this page

When this page changes, the date at the top changes with it. There is no notification when that happens, and no archive of previous versions.

Related

The terms of service cover who may create an account and what this service does and does not do.