Privacy Policy

• Account information: email, optional name and phone number, password hash (or magic-link state), and the organization(s) you belong to. When someone creates an organization, we email ourselves what they entered on the signup form (name, email, organization name, phone number if given, the plan they chose and how they heard about us) so we know a new organization has joined.
• Operator-supplied employee/student data: whatever fields you import (names, IDs, departments, photos, barcodes). You decide what to upload. The only required fields are an employee or student ID, a first name, and a last name.
• Templates, themes, and rendered badges: the design files you create and the PDFs we generate when you print.
• Operational telemetry: print job records (which operator printed which template at what time) and an audit log of staff actions. Each audit entry records the IP address and browser type of the staff member who acted. How long we keep both is under “How long we keep it” below.
• Product milestones: to see where setup gets stuck, we record steps like an organization being created, a card being printed, or roster sync finishing a run, and your answer if we ask whether your first card printed correctly. Counts are rounded into ranges, and these records never include the names, IDs, photos or details of the people on your badges. They stay in our own database. No Google Analytics, Mixpanel, Segment or advertising tools.
• Visits to our public pages: we count each view by page, the website that sent you (just its name, like google.com), a campaign code if the link carried one we set up, and your browser’s language. We keep daily totals, not a record of you, and never your IP address. HeyCatch, described next, is different: unless your browser sends Global Privacy Control or Do Not Track, it gives your browser a random identifier that lasts a year. We also set one first-party cookie (bb_src, kept up to 90 days) so that, if you sign up, we know which page or campaign brought your organization in. It holds no ID, is used for nothing else, and isn’t shared. If your browser sends Global Privacy Control or Do Not Track, we don’t count your visit and we drop that cookie. Visits from anyone who has signed in aren’t counted; to tell, we set a cookie (bb_member) that only says someone signed in on that browser.
• HeyCatch, on our public pages: we also use HeyCatch, an analytics service, to see how people find and use our public pages. On those pages it records the pages you view, what you click, the site or link that brought you, and your browser and device type, under a random ID it keeps in a cookie and in your browser’s storage for up to a year. Your browser sends this to HeyCatch directly, so HeyCatch also receives your IP address. It doesn’t record your screen, and it never runs in the app or on the signup form. If your browser sends Global Privacy Control or Do Not Track, it doesn’t run at all. HeyCatch’s privacy policy is at heycatch.ai/privacy.
• Print Agent pairings: if you install our optional desktop helper, the device’s hostname, the printer names it reports, and a bearer token used to authorize print dispatches to that machine.
• Roster files: if you turn on roster sync, the files your student information or HR system uploads to your drop folder. We delete each file once it’s applied, and after 14 days at the latest. The servers that receive the files keep access logs, described under “Service logs” below.
• Partner referrals: if a partner, such as the company that sold you a card printer, referred you through their link or code, we record that partner on your organization so we can pay them a referral fee. Their link sets a first-party cookie (bb_partner, kept up to 90 days) that holds only the partner’s code, so the referral still counts if you sign up later. If your browser sends Global Privacy Control or Do Not Track, we don’t set it. We tell that partner your organization’s name, its plan and what it paid, so they can check their fee, and nothing about the people on your badges.

We store your data in the United States. These services are involved:

• Database & file storage: Supabase, in AWS us-east-2. Postgres for structured records, S3-compatible object storage for photos and rendered PDFs, both encrypted at rest. For everything you do signed in to the app, the database’s row-level security policies keep each organization’s records separate. Requests made with an API token are limited to that token’s organization by our application code.
• Application hosting: Railway, in the United States. Stateless Next.js server; no persistent operator data lives here.
• Email: Resend sends invitations, password resets, sign-in links, account alerts, and messages from our contact form. While you try BadgeBadger, the person who started the trial also gets up to four setup tips, each with a link to turn them off. Which tip goes out, and when, depends on what your organization has done in the app so far: whether people have been added and whether cards have been printed. The tips stop once you print or pick a plan. Subject to Resend’s privacy policy.
• Billing: Polar. Payment-method details never touch BadgeBadger; Polar handles the card and PCI compliance.
• DNS & email forwarding: Cloudflare runs our DNS and forwards email sent to our help@ and hello@ addresses. App traffic doesn’t pass through Cloudflare’s proxy.
• Roster sync: Amazon Web Services. If you turn on roster sync, your roster files wait in a private Amazon S3 bucket in us-east-2 until we apply them.
• Optional AI features: the Scan card to template feature sends an image of an existing ID card to Anthropic for layout extraction. Anthropic does not train on this data per their commercial API terms. We only call out to Anthropic when an operator clicks the “Scan card” button.
• Support email: messages to help@badgebadger.app are forwarded by Cloudflare to a Gmail mailbox at Google, where we read and answer them.
• Website analytics: HeyCatch, on our public pages only, as described above.
• Fonts and open-source tools: the template editor loads fonts from Google Fonts, and the photo tools load open-source code and models from jsDelivr, Google Cloud Storage, and IMG.LY. Your browser fetches these files directly, so those services see your IP address, as with any web request. No badge data or photos are sent to them.
• Print Agent updates: the Print Agent downloads new versions from GitHub, which sees that computer’s IP address, as with any download. GitHub holds our code and the installer files, and no badge data or account details.

• We don’t use your data to train AI models, ours or anyone else’s.
• We don’t sell or share data with advertisers, brokers, or anyone outside the processors listed above, with one exception: a partner who referred you sees your organization’s name, plan and payments, as described under “Partner referrals” above, and never anything about the people on your badges.
• We don’t track operators across the web. No advertising scripts run on our site or in the app, and the app runs no third-party analytics. The one analytics service on our public pages, HeyCatch, is described above.

This is our data retention policy for the people your organization adds to BadgeBadger. It applies to every student, whatever the student’s age, and it’s the written policy the FTC’s COPPA Rule asks for (16 CFR 312.10).

Why we collect it. We use this information for one purpose: to make, print and manage the ID cards you ask for. We don’t use it for advertising, for building profiles, or to train AI models, and we don’t sell it.

• Name, and a preferred name if you add one: printed on the card, and how staff find the right record.
• ID number: matches roster updates to the right person, lets a student find their record at a kiosk, and is used for the card’s barcode.
• Photo, the original and the cropped copies we make from it: printed on the card. Keeping the original lets staff re-crop without taking a new photo.
• Signature, if you add one: printed on the card.
• Program or department, position, and class or school year: printed on the card, and used to choose the card design.
• Status, such as active or inactive: decides who can be printed, and keeps roster sync accurate.
• Card and print records: reprints, your own record of what you printed, and counting cards for your plan.

Only the ID number, first name and last name are required. You decide whether to add anything else.

Why we keep it. A school needs a student’s record while the student is enrolled and the school uses BadgeBadger. Lost cards get reprinted with the same photo. Students get a new card each year. Roster sync needs the ID number to keep each record current. When someone leaves, you decide when their record is no longer needed, and you can delete it at any time.

How long we keep each thing.

• People records, photos and signatures: until you delete the person or your account closes, whichever comes first.
• When you delete someone: we delete the record right away, along with their photos, signature, card records and print approvals. In the same step we delete everything else that names them: files in their folder, a photo they took with a capture link, print files with their card on them, their entries in roster sync history, and in-app notifications and webhook logs about them. A card still waiting to print is cancelled. Only admins and badge operators can delete people.
• Students who leave: roster sync marks them inactive but doesn’t delete them. Delete students who have left once they’re out of your school’s export, or the next sync adds them back.
• Replaced photos and signatures: deleted when you replace them. An hourly cleanup removes any copy left behind.
• Capture links: a link works once and expires after 10 minutes. The hourly cleanup deletes the uploaded original once it’s an hour old, and the link a day after it expires. Kiosk photos are saved straight to the record.
• Card scans: the image goes to Anthropic, which may keep it for up to 30 days under its standard API terms and doesn’t train on it. The hourly cleanup deletes our copy once it’s an hour old. Please scan a sample card, not a real student’s card.
• Print files: a card sent to the Print Agent is kept only until the job ends, and the person’s name is cleared from the job an hour later. A job no computer picks up fails after 7 days, and its file is deleted. The Print Agent deletes its own copy a few seconds after handing the card to the printer. Cards printed from the browser leave no copy with us.
• Roster files: deleted once applied, skipped or dismissed, and after 14 days at the latest.
• Roster sync history: lists problem rows by ID number, and the people a run marked inactive by name and ID number. Kept while the sync is set up. Deleted when you remove the sync or your account closes.
• Notifications and webhook logs: a notification can name a person, such as a card waiting for approval, and webhook logs hold their ID number. Both are kept until the person is deleted or your account closes. Removing a webhook deletes its logs.
• Print records and the audit log: who printed which cards and when, and what your staff changed, with the IP address and browser type of the staff member who acted. We keep them while your account is open, so you can check your own history and we can spot misuse and settle disputes. We don’t put names or photos in them. Entries about a person use internal record numbers, so once the person is deleted they no longer point to anyone. We can delete your print records sooner if you ask, and both are deleted with the rest of your organization’s records when your account closes.
• Emails: an approval request we email to your admins names the person. Resend delivers it and keeps sent messages and delivery logs for 30 days. We don’t store copies in BadgeBadger.
• Backups: the database is backed up every day and each backup is kept 7 days, so a deleted record can stay in a backup until it expires. Photos and other files aren’t in these backups, so a deleted photo is gone right away.
• Service logs: our hosting and database providers keep request and error logs, which can include record numbers or an ID number typed at a kiosk. Railway, our host, keeps them for up to 90 days, and Supabase, our database provider, for about a week. If you use roster sync, Amazon S3 keeps a log of each request to your drop folder (the time, the IP address, the key used and the file name) for 14 days, and our SFTP server records each connection (the time, the IP address and the username) in Railway’s logs, kept up to 90 days.
• Support email: if you or a parent email us about a student, we delete the message 90 days after we close the request.

When your account closes. An account closes when one of its admins asks us to close it, when we close it under our Terms of Service, or under the rule for unused accounts below. Cancelling a paid plan doesn’t close it: the account moves back to the free plan and its records stay. When an account closes, we delete all of its records within 30 days, including its print records and audit log, which go with the organization. Polar, our payment processor, keeps the payment records the law requires it to keep. If you ask, we keep your records up to 60 more days while you move to another system, then delete them. Before we close an account at your request, we confirm it with one of its admins.

Accounts no one uses. We may close an account that no one has signed in to for 12 months. We email its admins first and wait 30 days; if no admin signs in or replies, we close the account and delete its records as above.

How we delete. Deleting removes the information from our database and file storage. Nothing goes to an archive or a trash folder. Inside BadgeBadger, the only copy left is in the database backups, which expire within 7 days. Copies our providers hold are listed above.

Everything else. Your staff’s account details stay while your account is open. Product milestones are deleted along with the rest of your organization’s records, and other product events after 25 months. Public page counts are daily totals that can’t be traced to anyone, so they’re kept as they are.

Depending on where you live (GDPR, CCPA, FERPA, COPPA), you may have the right to access, correct, delete, or export the data we hold about you. Email help@badgebadger.app with the request and we’ll respond within 30 days.

BadgeBadger acts as a data processor for the employee/student records you upload; the organization that uploaded them is the data controller. Individual students or employees should make rights requests to their organization first.

BadgeBadger is designed to be FERPA-friendly: the only fields we require are an ID number, a first name and a last name, photos and IDs are stored under organization-scoped Supabase RLS, and we sign a Data Processing Addendum with K-12 districts on request. See the DPA template and email help@badgebadger.app to start the paperwork.

We treat every student as a child under the Children’s Online Privacy Protection Act (COPPA), whatever their age. BadgeBadger accounts are for school staff. Students don’t get accounts, and we don’t knowingly create one for a child under 13.

What we collect from or about students. Most of it comes from the school: the names, ID numbers, photos, signatures, programs and class years its staff add by hand, by import or through roster sync. A school can also have a student take their own photo with a one-time link on a phone, or use a kiosk the school runs on its own device, where the student types their ID number to find their record, takes a photo and prints their card. What we keep, why, and for how long is under “How long we keep it” above.

How we use and share it. We use it only to provide BadgeBadger to the school, and for no other commercial purpose. For students under 13, we rely on the school’s authorization, as the FTC’s COPPA guidance for schools allows: the school agrees to the collection on parents’ behalf. Nothing about a student is made public, and nothing in BadgeBadger lets a student make their information public. We share it only with the service providers listed under “Where it lives” above, for the purposes listed there. If the school connects its own systems through our API or webhooks, student information goes to those systems as the school sets up.

Parents. A parent can review their child’s information, have it deleted, or refuse further collection or use of it. Ask your child’s school, or email help@badgebadger.app. The school controls its students’ records, so we pass a parent’s request to the school’s admins and help them carry it out.

Who to contact. Po Studios LLC operates BadgeBadger and is the only operator collecting or keeping children’s information through it. Email help@badgebadger.app.

BadgeBadger is run from the United States and stores data there. If you use it from another country, your data is transferred to and processed in the US. For organizations covered by the GDPR or UK GDPR, our DPA includes the EU Standard Contractual Clauses and the UK addendum.

We process your account information to provide the service you signed up for. We process the people records your organization uploads on its behalf and on its instructions, as its processor.

We’ll email the account owner at least 30 days before any materially adverse change. Minor clarifications (typos, links, new sub-processors that don’t change the type of data collected) are reflected here without notice; check the “Updated” date above.

BadgeBadger is run by Po Studios LLC, a New Jersey limited liability company.

Privacy questions, data requests, and security reports: help@badgebadger.app. For a security report, put “Security” in the subject line.