Reveni - Reservas is a booking app for Shopify stores of class studios (yoga, pilates, workshops), developed by [FULL LEGAL NAME OF REVENI LABS] ("Reveni Labs", "we"), with Peruvian tax ID (RUC) [RUC] and registered address at [REGISTERED ADDRESS].
This document explains what personal data the app processes, why, where it is stored, for how long and what you can do about it. It is written for three audiences:
- The merchant: the studio that installs the app in its Shopify store.
- Students, who book and pay for their classes in that store.
- The studio's teachers, who sign in to their portal with their store account.
This is a translation of the Spanish original; if the two differ, the Spanish version prevails. If anything is unclear, write to ayuda@revenilabs.com and we will explain it.
1. Who is responsible for your data
Students' and teachers' data is processed on behalf of the studio: the merchant is the data controller (the owner of the personal database) and we are the data processor. We process that data following the merchant's instructions and only to provide the app's service. The terms of that processing are in our data processing agreement (in Spanish), which the merchant accepts when installing the app. If you booked a class or teach at a studio and want to exercise your rights, you can contact the studio or us: chapter 10 explains both ways.
The merchant's account data (the store domain, its contact email, its plan and how it uses the app) is processed by us as controller.
Shopify is an independent company with its own privacy policy. We access a store's data only with the permissions the merchant grants when installing the app. Payments are processed by Shopify: the app never sees or stores card data.
2. What data we process
2.1 Students
| Data | Where it comes from | What for |
|---|---|---|
| Name and email address | The Shopify order, when the class is bought | Each session's student list and emails about their booking |
| Shopify customer ID | The order, or their signed-in store session | Showing their bookings in "My bookings" when they sign in |
| Their bookings: class, date, price type, spots, order, payment and status | The booking and the order | Keeping each session's capacity, cancelling, rescheduling and refunding |
| Class credits | A cancellation, or a purchase without a date | Letting them use the credit for another session |
| Attendance | Marked by the teacher in their portal | The session's list and the teacher's earnings |
We do not ask for or store the student's phone number, address, date of birth or health data. Nor payment data: Shopify processes it.
While a student pays, the app holds their spot for 15 minutes. That hold carries neither their name nor their email, and it expires on its own.
2.2 Teachers
| Data | Who provides it | What for |
|---|---|---|
| Name, bio and photo | The studio | Published in the store next to their classes |
| Email address | The studio | The invitation to their portal and notices about their classes and earnings |
| Their customer account in the store | The teacher, accepting the invitation | Signing in to their portal |
| Their agreement (percentage or fixed amount) and earnings, with what the studio marks as paid | The studio | So the studio and the teacher can see what they earn. The app does not pay or move money |
| What they propose from their portal: classes with their photo, schedules and session changes | The teacher | Applying it, or leaving it for the studio to approve, depending on the permission the studio gives |
The portal invitation is a single-use link that expires after 7 days. Photos uploaded by a teacher are stored in the store's Content › Files, in Shopify, not on our servers.
2.3 What we read from Shopify
The app requests these permissions when installed:
- Required: read and write metaobject definitions and entries, the app proxy pages, read and write products, read and write orders, read customers, read and write draft orders, read locations, read themes, and read and write discounts.
- Optional, granted by the merchant only to upload photos: write files.
We request read customers (read_customers) for one reason only: without it Shopify does not return the buyer's name, and without the name there is no student list. From the customer we only read their ID, name and email, and only on the store's orders.
From the order we read exclusively: the order ID and number, the created, updated and cancelled dates, the payment status, the sales channel, the email, whether prices include taxes, the discount codes, the cart attributes, the customer's ID, name and email and, for each line, its ID, quantity, current quantity, variant, attributes, price after discounts and taxes.
We do not query the phone number, the billing address, the shipping address, the order note or the buyer's browser data.
The automatic notices Shopify sends us when an order changes are trimmed at the source and carry neither the name nor the email: only the customer ID, the order status and what each line needs to identify the class.
One exception we declare because it is real: the compliance notices Shopify sends when someone asks to see or delete their data (customers/data_request, customers/redact, shop/redact) arrive complete and do contain the person's email and phone number. We use them only to know whom to look for, and we empty that content from our records as soon as the job picks up the request, before any other step.
2.4 Merchant data
The store domain, its name, its contact email, its time zone, its currency, its language, the plan and the subscription status. The store's contact email is used as the reply-to address of the emails the app sends to students and teachers.
We do not receive or store card data. Shopify charges for the app on the store's bill.
2.5 Technical data
- Server and error logs, with automatic redaction: access tokens, signatures, the customer IDs Shopify passes in the URL and email addresses are replaced with
[redacted]before they are written. - Browser storage. The page with the class schedule stores in
localStorage, on the student's device, the view they chose (list or calendar; day, week or month). It is not personal data and it never leaves their browser. The app sets no cookies of its own and uses no tracking pixels.
2.6 What we do not do, said once
- We do not sell personal data or hand it to anyone for their own benefit.
- We do not use it for advertising or marketing: every email from the app is about the recipient's booking, class or portal.
- We do not use it to build, train or improve artificial intelligence models.
- We do not combine data across stores or across our apps.
- We make no automated decisions with legal or similarly significant effects on anyone, and we do no profiling. The only automatic action that affects a student is the refund when they pay late and the session has already filled up: the app returns the money and tells them.
3. Why we use each piece of data, and on what legal basis
| What for | Which data | Legal basis |
|---|---|---|
| Booking, keeping capacity and confirming the booking with the order | Order, booking and customer ID | Processing on behalf of the merchant, to provide the service the student asked for |
| Each session's student list and taking attendance | Name, email (only in the studio's admin), attendance | Processing on behalf of the merchant |
| "My bookings": cancelling, rescheduling and using class credits | Customer ID, bookings and class credits | Processing on behalf of the merchant |
| Telling a student that their session changed or was cancelled, and what they get back | Name and email | Processing on behalf of the merchant: it is information about their booking |
| The teacher portal, its notices and earnings | Data in section 2.2 | Processing on behalf of the merchant, within its relationship with the teacher |
| Billing and supporting the merchant | Data in section 2.4 | Performance of the contract with the merchant |
| Handling access and deletion requests | Whatever is needed to identify the person | Legal obligation |
4. What is visible, and to whom
| Where | What it shows | Who sees it |
|---|---|---|
| The store (each class page and the schedule page) | Classes, dates, spots left, prices and the teacher's name, bio and photo. Never student data | Anyone visiting the store |
| "My bookings" | The bookings and class credits of whoever signs in | Only the student, with their store account |
| Teacher portal | Their classes, their students' names to take attendance (without their emails) and their earnings, by class and session | Only that teacher, with their store account |
| Studio admin | Classes, sessions, students with name and email, orders, payments and teachers' earnings | The merchant and their staff, in the Shopify admin |
| Store metaobjects | Teachers (name, bio and photo) and sessions (date and spots). Never student data | The merchant; the theme uses them in the store |
The emails the app sends:
- To a student, when their session changes date, time or room, or is cancelled, with what they get back.
- To a teacher: the invitation to their portal, changes to their classes, their agreement and the payments the studio marks.
- To the studio: what its teachers change or request from the portal.
They go out through our email provider (chapter 5) with the studio's email as the reply-to address.
5. Who we share data with
Only with the providers we need for the app to work. All of them act on our behalf and under contract, and none may use the data for its own purposes.
| Provider | What for | Where it processes data |
|---|---|---|
| Vercel Inc. | Hosting the application and running scheduled jobs | United States |
| Supabase, Inc. | Database | United States |
| Resend (Plus Five Five, Inc.) | Sending the app's emails | United States |
| Shopify Inc. | The platform the store and the app run on; it stores the photos | See Shopify's privacy policy |
If we add or change a provider, we tell the merchant before it starts processing data.
We may also disclose data when a competent authority requires it through a valid legal channel, and in that case we tell the merchant unless the law forbids it.
6. Where data is stored, and international transfers
Data is hosted on servers in the United States (region us-east-1). This means that if you are in Peru or the European Union, your data leaves your country: it is an international transfer, and we say so plainly instead of hiding it in a footnote.
Peru has not declared that the United States offers an adequate level of data protection in general. We therefore rely on article 18.2 of the Regulation of Law 29733 (Supreme Decree 016-2024-JUS), which allows the transfer when the exporter provides adequate safeguards, and on its article 20, which accepts contractual clauses for that purpose. The safeguards we apply are:
- A written contract with each provider imposing at least the same obligations we take on.
- Encryption in transit and at rest, and additional application-level encryption of names and emails (chapter 8).
- A contractual ban on providers using the data for their own purposes.
- Registration of the transfer with the National Authority for Personal Data Protection where applicable, under article 21.2 of the same regulation.
If the merchant is subject to the European Union's General Data Protection Regulation: [HOW THE TRANSFER IS COVERED FOR MERCHANTS SUBJECT TO THE GDPR, TO BE DECIDED WITH THE RESERVAS DATA PROCESSING AGREEMENT].
7. How long we keep data
The general rule: data lives as long as the app stays installed in the merchant's store. When it is uninstalled, the data is deleted (chapter 9).
It is also deleted earlier in these cases:
| Situation | What happens |
|---|---|
| Someone asks the store to delete their data | See chapter 9. Maximum time: 30 days |
| The merchant uninstalls the app | We delete our copy within 48 hours of Shopify asking us to |
| A student cancels a booking | The booking is not deleted: it is marked cancelled, because there is a real order the studio has to account for |
| The package of an access request is delivered | The package is deleted 30 days after delivery |
Some data expires on its own, by design: the spot held while someone pays, after 15 minutes, and a teacher's invitation, after 7 days or once used.
Why there is no shorter period. While the app stays installed, the studio needs its booking history: each booking has a real order behind it that the studio must account for, and its teachers' earnings are calculated from them. That is why we don't delete them earlier on our own: they are deleted or anonymized through any of the routes in the table above. If we ever anonymize inactive students automatically, we will state it here with its period.
Backups. Our database provider keeps encrypted backups. A restored backup may contain data that had already been deleted: that is why we keep a record of the deletion requests we handled and apply them again to any restore. Backups are kept for [BACKUP RETENTION PERIOD OF THE PROVIDER].
8. How we protect it
What we actually do, without embellishment:
- Encryption in transit with TLS on every connection.
- Encryption at rest by the database provider.
- Additional application-level encryption with AES-256-GCM of the student's name and email and the teacher's email. Each ciphertext is bound to its row with additional authenticated data, so it cannot be moved from one person to another. The key for this data is different from the one protecting store access tokens, so one can be rotated without the other.
- A log of every decryption. Every time the system decrypts a name or an email, it writes an audit entry with who, which row, why and when. The decrypted value is never written to that log. It is the only path through which data can be decrypted.
- Isolation per app. Each Reveni Labs app has its own database schema and its own user, with no permissions on the others.
- Redaction in logs, applied when writing, not afterwards.
- Staff access limited to those who need it, with two-factor authentication on every console.
- Separate environments: testing happens in development stores with made-up data, and real data is not used in development.
What we do not claim: we have no ISO 27001 certification, SOC 2 report or any equivalent seal, and we will not suggest otherwise. No system is invulnerable. If a breach occurred, we follow the procedure and deadlines in chapter 11.
9. Deletion and access: Shopify's three cases
Shopify requires every published app to handle three automatic notices. All three are implemented, verified with a cryptographic signature and rejected with a 401 error if the signature is not valid. We reply immediately to confirm receipt, and the work is done afterwards by a scheduled job that runs every five minutes. The maximum time is 30 days, and an alarm goes off seven days before the deadline.
When someone asks to see their data (customers/data_request): we gather their bookings, their class credits and their decrypted name and email into a package delivered to the store owner, who downloads it from the app's admin, because they are the data controller. Every decryption is logged in the audit trail, and the package is deleted 30 days after delivery.
When someone asks to delete their data (customers/redact):
- We delete their name, email and customer ID.
- Their bookings are kept with nothing that identifies them, because they are real orders the studio must account for; their class credits stop belonging to anyone.
- We cancel any pending notices and empty the stored content of their order notices.
- If they signed in to the teacher portal with that account, we remove their access.
When the merchant uninstalls the app (shop/redact, which Shopify sends 48 hours later): we delete everything for that store from our database. The only thing that survives is the minimal record of the deletion requests we handled, with no personal data inside, which is our proof of compliance.
Two limits we declare because they are true and we do not want anyone to be surprised:
- What the app created inside the store stays there: the class products, the teacher and session metaobjects and the photos uploaded to Files. This is deliberate: they belong to the merchant, and none of them contains student data. Besides, Shopify revokes our access to the store 48 hours before asking us to delete, so we could not touch them even if we wanted to.
- An email already sent cannot be recalled. We delete our copy, but not the one in the recipient's inbox.
10. Your rights, and how to exercise them
You can request access to your data, its rectification, update, inclusion, deletion or cancellation, and object to its processing. You can also request portability of your data.
There are two ways, and both work:
Way 1, the studio. Write to the merchant whose store you booked in or teach for. They are the data controller. They pass the request to us through Shopify's automatic channel and we carry it out.
Way 2, us. Write to ayuda@revenilabs.com stating the store. If the request concerns data we process on behalf of a merchant, we forward it to them without delay and assist them, because the law requires us to act on their instructions. We will confirm we received it.
The fastest way: a student can cancel or reschedule their own bookings in "My bookings". A teacher can ask the studio to correct their profile or to unlink their account.
Legal deadlines in Peru, under articles 69 and 71 of the Regulation of Law 29733 (Supreme Decree 016-2024-JUS):
| Right | Maximum response time |
|---|---|
| Information | 8 days |
| Access | 20 days |
| Rectification, cancellation, objection | 10 days |
Deadlines run from the day after the request is filed and may be extended once, for the same period, when circumstances justify it; if so, you will be told within the original deadline. If we need more information to handle your request, we will ask for it and the deadline is paused until you reply.
When the request arrives through Shopify's automatic channel, the maximum time is 30 days, which is what Shopify requires of every app.
If you are not satisfied, you can file a complaint with Peru's National Authority for Personal Data Protection (Ministry of Justice and Human Rights). If you live in the European Union, with the supervisory authority of your country.
11. If a security breach occurs
We have a written internal procedure, with severities, owners and clocks. The essentials, so you know what to expect:
- We notify the merchant immediately, without waiting for the investigation to finish, as article 36 of Supreme Decree 016-2024-JUS requires of a data processor.
- We notify Shopify within 24 hours of becoming aware, as its partner agreement requires.
- When the severity calls for it, we notify the National Authority for Personal Data Protection within 48 hours (article 34.1 of the same regulation) and, if the incident happens in the digital environment, the National Digital Security Center too (article 34.5).
- We inform the affected people within 48 hours, in plain language and together with the merchant, when the incident affects their rights (article 34.3).
- If the merchant is subject to the European regulation, we notify them in time to meet their 72 hour deadline with their supervisory authority (article 33 of the GDPR).
12. Minors
The app is not aimed at minors. If a studio offers classes for children, the booking is made and paid by an adult with their own account, and it is their name that appears: the app does not ask for the child's age or name.
If you are a parent or guardian and believe we process a minor's data without your consent, write to ayuda@revenilabs.com and we will resolve it with the studio.
13. Changes to this policy
We may update it. Substantial changes are announced to the merchant by email or inside the app with reasonable notice, and the date below always says when it was last changed. The version in force is the published one.
14. Contact
[FULL LEGAL NAME OF REVENI LABS] [REGISTERED ADDRESS] Email: ayuda@revenilabs.com Data protection officer: [NAME AND EMAIL OF THE PERSONAL DATA OFFICER, IF ONE IS APPOINTED]
Last updated: October 25, 2026.