Trust & Security
Batch Relay connects guardians, studios, staff, athletes, storefronts, payments, APIs, and print providers. This page explains how the database, web app, Apple app, API, and fulfillment services divide responsibility.
Last reviewed: July 31, 2026
Interface visibility is not authorization, and a successful checkout page is not proof of payment or fulfillment. Batch Relay uses authenticated identities, backend checks, scoped working data, durable lifecycle records, and provider-specific execution boundaries so each layer verifies the work it owns.
Clerk establishes the signed-in identity. Convex then authorizes data access against the current guardian, studio membership, fixed staff role, and explicitly selected studio. A studio identifier sent by a browser or app is routing context—not proof of access.
Cross-studio operations fail closed when membership or active-workspace context does not match. This keeps authorization in the backend instead of relying on hidden interface controls or a client-supplied studio ID.
The shared Convex backend is the authorization and operational-data layer for both the web and native apps. Guardian media access is evaluated against the relevant athlete, event, team, studio, and privacy state before protected records are returned.
Studio capabilities separate viewing, management, fulfillment, catalog, analytics, and privacy responsibilities. The interface can present the appropriate workspace, but the database remains responsible for deciding whether the authenticated person may perform the operation.
The web app and Apple app use the same authenticated backend contracts. Switching interfaces does not create a separate authorization model or a less-protected copy of the studio workspace.
The native studio CRM keeps a bounded, privacy-filtered working set and clears it when the active studio changes. It excludes image bytes and bulk guardian contact or address data. Current mutations remain online and server-authorized; there is no silent persistent offline outbox replaying private changes later.
Stripe-hosted flows collect payment methods and manage regulated card handling. Batch Relay stores the order, checkout, payment, fee, connected-account, and fulfillment references required to operate and reconcile the transaction; it does not need to store raw card numbers.
A successful return page is not proof of payment. Verified Stripe events advance payment state, and payment state remains distinct from provider submission, lab production, shipment, studio settlement, refunds, and reprints.
Batch Relay owns the provider-neutral order and fulfillment record. Provider adapters translate that record for White House Custom Colour or Richmond Pro Lab. The selected provider and production contract stay attached to the order so the system does not silently substitute a lab.
Provider credentials remain on server-side execution paths, outside parent storefronts and pilot automation recipes. Batch Relay preserves submission state and provider responses; the lab still controls manufacturing quality and production timing, while the carrier controls transportation and final delivery timing.
Checkout, API submission, provider handoff, and settlement use stable identifiers and idempotency controls. A safe retry can return the recorded result instead of creating duplicate work, while reuse of an idempotency key for different order data is rejected.
Fulfillment jobs preserve submission state and exceptions. Provider acknowledgements, shipment updates, reprints, refunds, and financial transfers remain separate lifecycle events so an operator can identify which handoff failed and reconcile the correct record.
The developer API and pilot automation connections use Batch Relay as the controlled boundary between a workflow tool and the fulfillment providers behind it.
Premium service is clearer when responsibilities are named. Batch Relay coordinates the workflow, but studios, payment providers, labs, and carriers still control important inputs and outcomes.
Batch Relay retains operational information while it is needed to run the service, resolve orders, maintain business and payment records, investigate issues, and meet legal obligations. The need differs between an unsubmitted draft, paid order, provider handoff, and completed financial record.
The product includes a privacy deletion-request workflow for guardian profiles and linked athlete data. Requests move through review and processing rather than pretending every related record can disappear instantly. Legal, security, payment, dispute, and operational limits may require some records or de-identified references to be retained.
The current privacy policy governs website and business-contact data. Customer agreements can add product-specific terms for production data and service providers.
No connected system can promise zero risk, uninterrupted availability, perfect lab output, or guaranteed carrier delivery. This page describes the current product architecture and operating responsibilities; it is not a substitute for a signed agreement, data-processing addendum, or independent security certification.
Batch Relay does not currently advertise a certification such as SOC 2. Studios with procurement, retention, insurance, incident-response, or contractual requirements should raise them during onboarding so the current controls and any gaps can be reviewed directly.
Bring the workflow, identities, data, payment model, automation, provider handoffs, and recovery requirements for one real event. We will map the current controls and identify anything that needs a direct answer before your studio relies on the system.
Plan your first event