Trust
Sub-processors
Last updated September 30, 2026
These are the third parties that help us run Jettova. We list each one, why we use it, and what category of data it processes. This list reflects the vendors actually integrated in the product; we update it as our infrastructure changes. Jettova for Schools uses a shorter list, with what each vendor receives on a school trip and when it is used: see the Jettova for Schools section.
Infrastructure and service sub-processors
| Sub-processor | Purpose | Data category processed |
|---|---|---|
| Supabase | Managed Postgres database, authentication (incl. SSO/SAML & SCIM for Teams), and storage | Account and profile data, trip content, org membership and roles, hashed credentials/tokens |
| Vercel | Application hosting and content delivery | Request metadata and IP address (per-request geo is computed and not stored) |
| Anthropic | AI trip planning, reading receipts and booking confirmations, and checking that an uploaded permission form looks signed | Trip planning inputs; receipt and booking-confirmation images (read, then discarded, not stored); uploaded permission forms, sent whole for the signature check (the form itself is stored by Jettova, not by Anthropic) |
| Stripe | Payment processing and subscription billing | Billing contact and payment details entered directly with Stripe (Jettova stores no card data) |
| Duffel | Flight and stay search and booking infrastructure | Search parameters such as routes, dates, and traveler counts. Where a school books flights centrally through Jettova (off unless the school enables it), each traveler's legal name, date of birth and gender, which Duffel passes to the airline to issue the ticket |
| Foursquare | Venue and place data used to verify suggested venues | Place names from itineraries and event venues, with the event venue's or destination's coordinates (no account, family or student identifiers) |
| Resend | Transactional and notification email delivery | Recipient email address and message content |
| Firebase Cloud Messaging (Google) | Push notification delivery to Android and web devices | Device push tokens and notification content |
| Apple Push Notification service (Apple) | Push notification delivery to iOS devices | Device push tokens and notification content |
| Upstash | Redis-backed API rate limiting | Rate-limit keys and counters; each key is a one-way keyed hash of an API key, IP address, sign-in email or internal identifier |
| Sentry | Application error monitoring | Diagnostic and error data, which may include limited request context |
Travel and commerce partners
Jettova is not the merchant of record for bookings made with the partners below: you transact on the partner's own site under their terms and privacy policy. Jettova generally sends only search parameters or referral click-throughs, not your payment details.
| Sub-processor | Purpose | Data category processed |
|---|---|---|
| Expedia Group | Flights and hotels (affiliate links / inventory) | Search parameters; bookings and payment occur on the partner's own site |
| Viator | Tours and activities (affiliate links) | Search parameters; bookings and payment occur on the partner's own site |
| Kayak | Flight and hotel meta-search (affiliate links) | Search parameters; bookings and payment occur on the partner's own site |
| Travelpayouts | Affiliate network and real-fare data for estimate accuracy | Search parameters and fare lookups (no account identifiers) |
| Airalo | Travel eSIMs (affiliate links) | Referral click-through; purchase occurs on the partner's own site |
| Ticketmaster | Live-event listings and links | Event queries; purchase occurs on the partner's own site |
| Unsplash | Destination imagery | Image search queries (no personal data) |
| impact.com | Affiliate attribution on our consumer travel pages, so a travel partner can credit a booking to Jettova. Never on Jettova for Schools pages or in any trip room | The page address and a visit identifier (no name and no trip details) |
Jettova for Schools
The vendors that can process school or family data on a Jettova for Schools program, what each receives, and when it is used. A school's family payments run on the school's own Stripe account, so the school is the merchant of record. School trips send no push notifications, so no app push service receives school trip content. If your district needs a vendor removed or substituted, tell us and we will say honestly whether we can.
| Sub-processor | What it does for a school | What it receives | When |
|---|---|---|---|
| Supabase | Our database, sign-in and private file storage, and the live channel that tells an open trip page it has changed | All school data, encrypted at rest. The live channel carries a signal that the trip changed and who in the room is online, not the trip's contents | Always |
| Vercel | Hosting the application and running our server code, so every request that reads or writes school data passes through it while it is served. It also holds our server's encrypted configuration | Everything a request carries passes through it while it is served. What it keeps is request records (IP address, time, and the page or route address, which for a trip includes its trip code) and our own server logs, which on school paths record internal identifiers and error details. Its analytics products are switched off on every school page | Always |
| Stripe | Family payments, on the school's own connected Stripe account. The school is the merchant of record | Amounts, currency, payment references, the trip name, and the payer's own card or bank details, entered directly with Stripe. Jettova never receives card numbers. When a school sets up its account, its business details, representative's identity and bank details go directly to Stripe | When a trip collects payments online |
| Resend | Trip emails: invitations, personal roster invitations, account setup links, the chaperone day-of link, reminders, announcements and approvals | The adult recipient's email address and the email's content | Always |
| Sentry | Telling us when something breaks | Error and performance diagnostics with the page address and limited request context. Payment-link tokens and device credentials are stripped out before anything is sent. Session replay is not enabled | Always |
| Upstash | Rate limiting, to slow down abuse | Counters keyed by a one-way hash of an IP address, sign-in email or internal identifier. No names and no content | Always |
| Anthropic (our AI provider) | Drafting help for staff, such as formatting a pasted itinerary, drafting a trip plan or a reminder message | The trip details, itinerary text and notes staff give it, which can include a student's name if staff typed one in. It never gets the family roster. If the automatic permission-form check is switched on, the uploaded form itself, which can carry health details | Only when staff use a drafting feature. The permission-form check and booking-confirmation reading are switched off |
| Foursquare | Finding a venue's location and checking that suggested places exist | Place names from the itinerary and the event venue, with the venue's or destination's coordinates. No account, family or student identifiers | When staff add a venue or draft a trip plan |
| Duffel | Flight and hotel search, and booking where a school turns on managed travel | For search: routes, dates and group size, with no names. For managed booking only: each traveler's legal name, date of birth and gender, which go to the airline to issue the ticket | Search when someone opens flight options for a trip. Managed booking is off unless the school turns it on |
| Blackbaud | Importing the roster from the school's own student information system | The roster data the school's own Blackbaud account returns | Switched off. If we turn it on, only when the school connects its own Blackbaud account |
| Google and Apple | Sign-in, if a family or staff member chooses Continue with Google or Sign in with Apple | The sign-in itself. They tell us your name and email address; we send them nothing about the trip | Only if a person chooses to sign in with them |
| Photon (komoot), OpenStreetMap Nominatim and Wikipedia | Backup place lookups, to put an itinerary's venues on the trip map when our main venue lookup finds nothing | A venue name from the itinerary, with its city or the city's coordinates. Each name is looked up about once and then cached. No account, family or student identifiers | When a trip map has a venue the main lookup could not place |
| OpenStreetMap, Unsplash and Wikimedia Commons | Map tiles and destination photos on trip pages | Our server may look up a destination name to find a photo. Otherwise nothing from our systems: the viewer's own browser loads the map area or photo, which shares the viewer's IP address. No trip code, name or credential | When a page shows a map or destination photo |
| Slack | Trip notices in the school's own Slack workspace, and alerts to our own team when something needs our attention | In the school's workspace: notices that name the trip, such as its destination, its dates, or that a family needs help. A help request on a school trip names nobody; staff see who in the trip itself. In our team's alerts: internal record numbers, trip codes and sometimes a trip's name, never a family's or student's name. When a staff member asks us to set up a program, their name, email and school | The school's workspace only if the school connects it. Our team's alerts when something on a trip needs our attention, or a program is requested |
| Expedia and Ekta (affiliate links) | Optional lodging, flight and travel-insurance links on staff trip pages | Nothing from our systems. A staff member's own browser follows the link only if they click it. It carries the channel it came from, never the trip's room code or any name | Only if a staff member clicks one. Families never see these links |
See also our Security overview, Data Processing Addendum, Data residency, and Privacy Policy.
Questions about a specific vendor? Ask us directly.