Privacy Policy

1. Three kinds of people appear in esadesk

Vendors are our customers: tutors, therapists, microschools and enrichment programs who invoice state ESA programs. They have an account with us and they agreed to the Terms of Service.

Parents and students do not have accounts and have not agreed to anything with us. Their information is in esadesk because a vendor entered it in order to invoice for work done for that family. The vendor is the one with the relationship, and the one who decides what to enter. We hold it on their behalf and use it to run the product for them, not for anything of our own.

If you are a parent and you want to know what a particular vendor holds about your family, ask the vendor first. If you cannot reach them, write to us at requests@esadesk.com and we will help.

2. What is actually stored

About a vendor

• the email address used to sign in
• business name, contact email, contact phone, business address, licence number, website, an uploaded logo, an accent colour, and the short name used in parent links
• settings that change how the product behaves: the follow-up clock, how long finished invoices stay on the parent page, whether product updates are shown, and the labels of any custom invoice fields
• which state programs a vendor has told us they applied to or been approved for, and which readiness items they have ticked. These are statements the vendor makes about themselves, not anything we verify
• a record of each document-reading attempt: which feature, how many tokens, and whether it worked. Never the document, never what was in it
• if you subscribe: which plan you are on, the status our payment processor reports for it, how long your trial runs, and the two reference numbers that company gives us for your customer and subscription records. No card details, ever
• sign-in codes: the email address, a hashed code, a hashed link token, an expiry and an attempt count. The code itself is never stored in a readable form

About a parent

• name, and email address or phone number if the vendor entered one
• which state program the family is in
• whether the family agreed to text messages. Nothing in esadesk sends a text message today; the field exists so consent is on record before that ever ships
• free-text notes the vendor writes about the family, and a note recorded when contact details change
• signals from the invoice link: when it was opened, when the PDF was downloaded, the browser user-agent string of whoever opened it, when the parent pressed the button saying they submitted it, and what they wrote if they reported a rejection
• when a packet email is sent, the recipient address and the delivery outcome, including bounces and, where the mail provider reports them, opens and clicks

About a student

The student record itself holds five things, and this is the complete list:

• the student’s name
• a short web address made from that name, used in vendor-facing links
• a typical charge, in cents
• what the vendor does for them, such as “math tutoring”
• a billing rhythm

There is no date of birth, age, grade, school, home address, disability, diagnosis, photograph, ESA account number, or government identifier anywhere in the student record, and no screen in esadesk asks for one.

Four honest qualifications to that, because a short list can mislead:

• Invoices and any service records name a child alongside dated lines describing what was done for them. That is what an invoice is.
• Custom invoice fields and family notes are free text a vendor controls. A vendor could put a program account number or something more personal there. Nothing stops them, and we would rather say so than pretend the shape of the database is the whole answer.
• Which program a student is in can itself be revealing. Texas PDSES, for instance, is a special-education program, so knowing a student is on it says something about that student.
• A rejection screenshot uploaded by a parent is a photograph of a platform screen. It can contain whatever the platform was showing at the time.

Invoices and their history

Invoice numbers, dates, titles, line items, amounts, platform fees, which payment lane was used, the statements the vendor ticked, the frozen record of what our checks said, and the generated PDF. Alongside each invoice sits its history: an append-only list of everything that happened to it, which is the point of the product and the subject of section 8.

Files

Vendors upload documents, and parents can attach one. Each is stored as a file:

• professional credentials, teaching certificates, licences and insurance documents
• a W-9, if the vendor chooses to keep one in esadesk. We have no field for a taxpayer number and never ask for one, but a real W-9 has one printed on it, so a vendor who uploads theirs has stored it with us as a document
• proof of payment for reimbursement claims, which is usually a bank or card statement line or a payment-app screenshot. Where a state requires the invoice and the proof to be one document, esadesk merges them at send, so the parent and the platform see it. That is the purpose of the file
• a vendor’s own invoice PDF, where they would rather send their own document
• a business logo
• a screenshot of a rejection, if a parent attaches one when reporting it

We do not open these files or scan their contents except when a vendor asks a screen to read one, which is section 6.

Technical information

• Our hosting provider keeps ordinary web server logs, which include IP addresses, as any web host does.
• Our own database does not store IP addresses. The counter that limits sign-in attempts and parent-page traffic stores a one-way hash of the address or token, never the address or token itself.
• Vendor pages and public pages load measurement scripts from our hosting provider: one measures page performance, one counts page views. Both are aggregate and cookie-free, and neither identifies anyone. They are deliberately not loaded on parent pages, which run with no client-side JavaScript at all.
• The only cookie esadesk sets is the sign-in cookie. It is signed, HTTP-only, tied to your account, and lasts seven days or until you sign out. There are no advertising cookies and no third-party trackers.
• Application logs record errors by shape and status code. Student and parent names, file contents, and extraction results are never written to them.

3. What we never ask for

• Platform credentials. Never, in any form. esadesk does not sign into ClassWallet, Odyssey, EMA or Student First, and there is nowhere in the product to type those details. This is a rule we hold ourselves to at the level of the architecture, because a vendor’s platform account is their livelihood.
• Passwords. There are none. Sign-in is a code emailed to you, so there is no password of yours for us to lose.
• Bank or ACH details. Never stored, not encrypted, not “just for onboarding”. The registration checklist can only ever record that a vendor has their bank details ready for the state’s own form.
• Payment card numbers. Subscriptions are handled by a payment processing company. You type your card on its pages, not ours, and the number never reaches esadesk. What comes back to us is a reference number for your customer record, a reference number for the subscription, the plan, and its status. There is nowhere in esadesk to type a card number.
• Anything collected from a child. No part of esadesk is used by a student.

One word deserves clearing up: when esadesk says credential, it means a professional qualification document such as a teaching certificate or a licence. It never means a username or a password.

4. Why we hold it

To run the product a vendor is paying us to run, and for nothing else. Concretely: to compose an invoice and check it against a program’s rules, to produce the document, to show the parent a page they can act on, to record what happened so a vendor can prove it later and chase what stalled, to send the emails a vendor asks us to send, to keep the service secure and within its limits, and to answer support questions.

We do not sell personal information, we do not share it for advertising, and we do not use it to train AI models.

5. Who else touches it

Running esadesk means a few specialist companies process data on our behalf, under contract and on our instructions. These are all of them, by what they do:

Each has its own terms and its own security posture, and we rely on them the way any small product does. If we add or replace one, this page changes with it.

6. Document reading

Several screens can read a document and fill a form in from it: an old invoice, a roster, a W-9, a certificate. It only ever happens when a vendor asks for it.

• What is sent. The file itself, to our document-reading provider, together with an instruction describing the fields to look for.
• What we keep. Nothing of the document. The bytes are held in memory for the length of the request and are never written to our storage or our logs. What we record is a single row saying which feature ran, how many tokens it used, and whether it succeeded. Never the content.
• What comes back is a suggestion. It lands in a form for the vendor to check and correct. Nothing saves until they save it, money is recalculated on our side rather than trusted from the model, and a student is never created from a document.
• Training. We do not use anything in esadesk to train AI models. That provider’s published policy for its commercial API states that, by default, it does not use inputs or outputs from its commercial products to train its models. That is their policy and their commitment, not ours to give; it is published here.
• You can simply not use it. Every screen with document reading works by hand, and the spreadsheet import never uses a model at all.

7. The parent link, and what it exposes

Parents never make an account. They get a long link, and the link is the credential. That was a deliberate decision: a parent opening an invoice on a phone, on a bad connection, in the middle of something else, should not have to make a password to pay their tutor. It has a cost, and this is it, stated plainly.

• The link ends in a random tail of roughly forty bits, generated by a cryptographic random number generator. It is not guessable in any practical sense, but it is not a secret we can take back once it has been forwarded.
• Anyone holding an invoice link can see the student’s name, the parent’s first name, the vendor’s business details, the invoice title, number and total, the invoice PDF where the program allows it to be shared, and, on reimbursement claims that need it, the vendor’s credential document.
• It also links to the family’s standing page, which lists that family’s students and their invoices with that vendor, and links to each of those invoices. So an invoice link does not expose one invoice. It exposes that family’s billing history with that vendor.
• Anyone holding the link can also act without signing in: mark the invoice submitted, undo that, or report a rejection with a message and a photograph. Those actions are recorded in the permanent history, and the record does not know who pressed the button. It only knows the link was used.
• Retiring a link. A vendor can rotate the family’s standing link from the family page, which stops the old one working immediately. There is no button today for retiring a single invoice link. If a link has gone to the wrong person, tell us at requests@esadesk.com and we will deal with it directly.
• Parent pages ask search engines not to index them, and they load no analytics and no client-side JavaScript.

8. History, deletion, and how long things stay

The history of a claim is append-only, enforced by the database itself: rows can be added, and cannot be changed or removed. That is on purpose. It is the evidence a vendor relies on when a platform says an invoice was never submitted, and a history that can be quietly edited is not evidence. Corrections are made by adding a new entry, never by rewriting an old one.

The practical consequences, stated honestly:

• A vendor can delete, in the product: a note about a family, a document in the Vault, a registration tick, an automation. Deleting a document removes both the record and the stored file, unless another invoice still relies on that same file as evidence.
• A vendor cannot delete, in the product today: a family, a student, an invoice, a claim, or its history. There is no button for it, and there is no cascade behind the scenes.
• There is no automatic deletion. We run no retention schedule and no expiry job. What is entered stays until someone removes it. Documents with an expiry date are flagged as expiring; they are not deleted.
• Sign-in code rows are kept. A code is single-use and expires in ten minutes, but the row, which carries the email address it was sent to and the hashes, is not currently cleared out.
• Backups. Our database provider keeps its own backups, so removed data can persist there for a period after we delete it.

If you want something removed, write to requests@esadesk.com. We will remove by hand what can be removed, and we will tell you plainly what cannot and why. We would rather say that than publish a deletion promise the product cannot keep.

One thing worth knowing before asking us to erase everything: for many ESA vendors these are the only records of that income anywhere, because the platforms often issue no year-end tax form. Export first. The export tells you why it matters.

9. Getting your records out

Any vendor can export their whole book from the Vault at any time, as a folder of invoice PDFs organised by student, an income summary, a plain list of confirmed money, the full history as a spreadsheet, and a written explanation of what is in it. It is deliberately readable by a person, not just by us. Those files name students, because that is what makes them useful as records.

10. Security, and what we do not have

What is actually in place:

• everything travels over HTTPS
• the database provider encrypts data at rest
• no passwords exist to be stolen, and sign-in codes are hashed
• the sign-in cookie is signed and HTTP-only, and a vendor can invalidate every session on every device from Settings
• every screen and every action is scoped to one vendor’s book, and that boundary is covered by an automated test suite that runs one account’s session against another account’s records and checks nothing moved
• uploaded files are served only through our own routes, which check who is asking
• sign-in and parent pages are rate limited
• uploads are checked by content, not by file extension, and are size capped

What we do not have, said out loud:

• Student and parent names sit in ordinary database columns. They are not separately encrypted field by field, which means anyone with access to the database can read them. That is a known trade-off rather than an oversight, and it is why the next section exists.
• No security certifications. We do not hold SOC 2, ISO 27001, or any equivalent, and we do not claim to. We are not a HIPAA business associate and will not sign a BAA today.
• No dedicated security team, no bug bounty, and no round-the-clock monitoring. esadesk is early software.

If you find a security problem, write to requests@esadesk.com. We would much rather hear it from you.

11. Who at esadesk can see your data

Our staff administer the production database and can read what is in it, including vendor details, parent contact details and student names. They do so to keep the service running, to fix things, and to answer support questions, not to browse. There is no in-product screen that shows one vendor another vendor’s book; this is direct database access, which is how small products are operated, and we would rather you knew it than assumed otherwise.

12. Children’s information

esadesk has no child-facing surface. No student signs in, receives an email from us, or types anything into the product. Student information reaches us because a vendor entered it about their own customer in order to invoice for work already done.

Because we do not collect anything from children, the US Children’s Online Privacy Protection Act rules about collecting from children under 13 do not apply to us. We are not a school or an education agency, so FERPA does not apply to us either. Those are statements about how the product works, not certifications, and we are not claiming compliance with any standard.

If you are a vendor with obligations of your own, under HIPAA as a therapist, under a contract with a school or a program, or under a state privacy law, deciding whether esadesk fits those obligations is your call to make. We have tried to make that easy by describing exactly what is stored rather than summarising it.

13. Where it is held

esadesk is operated from the United States, and the companies in section 5 are United States companies. If you use esadesk from outside the United States, your information is processed in the United States.

14. If something goes wrong

If we find out that information in esadesk has been exposed, we will tell affected accounts without undue delay, describe what we know and what we do not yet know, say what we have done, and say what you may want to do. We will not wait until the picture is complete to say something happened.

If it involves a family’s information, the vendor is the one with the relationship with that family and may have a notification duty of their own. We will give you what you need to meet it.

15. Asking us for something

Write to requests@esadesk.com. You can ask for a copy of what we hold, though the Vault export is usually faster and more complete; ask us to correct something, though most of it is editable in the product; ask us to delete what can be deleted, subject to section 8; or ask us to close your account. We will not charge you for any of this, and we answer as quickly as we can.

16. Changes to this policy

When the product changes what it stores, this page changes too, and the date at the top moves. If a change is significant we will email the address on your account.

17. Contact

esadesk is operated by Sunday Maple LLC, a New York limited liability company. Email requests@esadesk.com, or write to: