01 · In brief
A plain-language summary
VeloCare helps riders manage bicycles, record rides, request AI-assisted visual-condition reports, maintain care tasks, and manage VeloCare Pro.
VeloCare requires an account using Sign in with Apple or Google Sign-In. The current iOS app does not offer a username/password or email/password sign-in form. Precise location is collected during a rider-started active ride, and a route is uploaded only after the rider finishes and saves the ride. Bicycle scan photos are uploaded only after the rider requests analysis and grants the in-app AI-sharing permission.
For an AI-assisted report, VeloCare sends selected bicycle photos and limited bicycle details to OpenRouter, which routes the request to the downstream AI model provider configured by VeloCare. VeloCare also uses limited first-party product analytics to understand app activity, retention, onboarding, paywall activity, app-version coverage, and product effectiveness. It does not use a dedicated third-party analytics SDK, sell personal data, display targeted advertising, or use this telemetry for advertising or cross-app tracking.
Riders can export the active product data described below, delete individual reports and rides, revoke future AI-analysis permission, or permanently delete their account. Account deletion removes most account-linked active product data, but certain unlinked, aggregate, security, audit, deletion-proof, provider, and operational records may remain as explained in Account deletion.
02 · Scope
What this policy covers
This policy covers the VeloCare native iPhone and iPad application, VeloCare’s custom backend and API supporting the application, VeloCare support communications, and the public VeloCare website only to the extent described in Website data.
This policy does not govern Apple, Google, RevenueCat, OpenRouter, the downstream AI model provider, hosting providers, database providers, or email providers. Those providers have their own privacy notices. VeloCare selects and uses them for specific features, as described in Service providers and data recipients.
03 · Controller
Who controls your information
- Product
- VeloCare
- Controller
- Seif Amara
- Postal address
- Tunisia
- Country of establishment
- Tunisia
- Privacy contact
- dhibi.ywsf@gmail.com
04 · Data practices
What VeloCare collects and why
The table below describes the product data and operational data identified for the current VeloCare iOS app and custom backend. A retention period is stated where the current product configuration supports one. Provider-controlled retention is kept separate from VeloCare’s own retention.
| Category | Examples | How collected | Purpose | Where processed or shared | Retention |
|---|---|---|---|---|---|
| Account and identity data | VeloCare account UUID; name; email, including an Apple private-relay address when selected; email-verification state; account timestamps and status; block information; provider type, provider-specific user identifier, and provider client identifier; encrypted Apple refresh token when needed for deletion-time revocation; session version and activity timestamp. | Sign in with Apple, Google Sign-In, and direct profile edits in VeloCare. | Create and authenticate the account; restore saved product data; secure sessions; connect purchases, bicycles, rides, reports, and tasks; prevent fraud and unauthorized access. | VeloCare’s API and database; Apple or Google for authentication; RevenueCat for subscription identity and lifecycle synchronization when applicable. | Active account and provider-link records remain until account deletion. Session credentials last until expiration, invalidation, logout, or account deletion. Separate security and audit records follow the criteria described below. |
| Onboarding, rider, and bicycle profile data | Riding goal; experience level; preferred terrain; rides per week; weekly distance target; maintenance confidence; bicycle name, type, brand, model, model year, brake type, last-service range; optional drivetrain, frame material, wheel size, other details; lifetime distance. | Directly entered or edited by the rider in VeloCare. | Personalize VeloCare; manage the bicycle garage; calculate progress; provide relevant maintenance and scan context. | VeloCare’s API and database. Applicable bicycle details may be shared with OpenRouter and the configured downstream AI model provider only for a requested AI scan, as described below. | Until edited, the bicycle is deleted, or the account is deleted. |
| Precise location and ride data | Precise latitude and longitude route points; timestamps; route segments; ride start and end times; time zone; distance; elapsed and active duration; average active speed; selected bicycle and name snapshot; weekly ride progress; highlight/star status; ride-share layout settings. | Precise location from iOS Core Location during a rider-started active ride; other ride details from the app and rider actions. | Record and display rides; calculate progress; preserve ride history; support ride sharing. | Held in a protected local draft while active. Sent to VeloCare’s server only after the rider finishes and chooses to save the ride. Apple may independently process location and system requests according to its terms. | A saved precise route remains until the ride or account is deleted. A discarded ride draft is deleted rather than uploaded. Lifetime bicycle mileage remains after an individual ride is deleted and lasts until the bicycle or account is deleted. |
| Bicycle photos, camera, photo library, and ride-share content | Selected drivetrain-side, front, rear, or focused-area photographs; ride-share background photographs; rendered ride-share images; image dimensions, quality metadata, and capture roles. | The camera when the rider chooses to photograph a bicycle or capture a ride-share background; the iOS photo picker when the rider selects a photograph. The picker receives only the selected photograph, not the entire library. | Run a requested bicycle scan; preserve a saved report’s media; create a ride-share image when requested. | Photos selected for AI analysis are converted to JPEG and uploaded to VeloCare’s private server. Ride-share backgrounds and rendered ride-share images are generally processed on-device and saved to Photos or shared only when requested. | Raw/staging media and saved report-image derivatives are removed according to server-configured retention windows or earlier deletion. The deployed values can differ from repository defaults. Temporary on-device files are cleaned after use, through applicable sign-out cleanup, or through stale-file cleanup. |
| Reports, findings, maintenance, and user content | Scan status and timestamps; image dimensions and quality; AI request metadata; token counts, latency, response identifiers, and provider cost; visible-condition score; image quality; summary; findings and confidence; limitations; component coverage; maintenance tasks and recommendations; due/reminder dates; priority; pinned/completed state; notes; scan-quota usage. | Generated from scans and service operation, or entered and edited by the rider. | Deliver and preserve reports; track care history; generate and manage tasks; operate subscription scan quotas; troubleshoot provider failures and service quality. | VeloCare’s API and database; OpenRouter and the configured downstream AI model provider for requested AI processing; hosting and database providers as applicable. | Account-linked information remains until the applicable report, bicycle, or account is deleted, subject to separate report-image expiration and legitimate backup/provider copies. |
| Purchases and subscriptions | RevenueCat customer/app-user identifiers; product and provider subscription identifiers; access, entitlement, renewal, expiration, billing, environment, and store state; purchase, renewal, cancellation, expiration, refund, and revocation events; transaction identifier; amount, currency, and price/tax/commission values when supplied; aliases and transfer relationships; webhook state, retries, failures, and timestamps; scan-quota periods, consumption, reservations, denials, and adjustments. | Apple App Store transactions, RevenueCat SDK/service events, and VeloCare server synchronization. | Load plans; verify entitlements; restore purchases; synchronize subscription lifecycle; apply scan quotas. | Apple and RevenueCat. VeloCare stores normalized subscription status and related operational metadata. VeloCare does not receive or store payment-card numbers. | Account deletion removes active customer mapping, entitlement, access grants, and account-linked subscription associations and queues RevenueCat customer erasure. Raw RevenueCat webhook-event and customer-alias history has no automatic time-based purge and is not currently removed by the local account-deletion transaction. |
| First-party product-interaction analytics | Seven event types: app_opened, onboarding_started, onboarding_step_viewed, onboarding_step_completed, onboarding_completed, paywall_viewed, and paywall_dismissed. Events can include random installation, per-process/session, and event UUIDs; schema version; timestamp; app version/build; iOS or iPadOS and OS version; onboarding flow, step, index, and completion duration; paywall context; and selected subscription product identifier when available. | Automatically generated by the VeloCare app. Pre-authentication events are initially associated with a random installation UUID. If a later authenticated telemetry request contains that UUID, the backend links earlier events from the installation to the VeloCare account. | Measure app activity and retention; onboarding progression and abandonment; paywall activity; app-version coverage; and product effectiveness. | VeloCare’s custom API and database. VeloCare does not use Firebase Analytics, PostHog, Mixpanel, Amplitude, Sentry, or another dedicated third-party analytics SDK for this telemetry. | The server rejects events more than 30 days old at ingestion, but that is not a stored-data retention period. Account-linked raw events are deleted with the account. Raw unlinked events have no automatic expiration. Daily aggregate counts and distributions contain no account, installation, session, or event identifiers and may remain after raw records are deleted. |
| Login, account-integrity, security, and administrative-audit records | Login provider, outcome, timestamp, optional account ID, app version, platform, user agent limited to 512 characters, and an HMAC-hashed representation of the observed IP address; current block status, block and optional expiration timestamps, internal reason, responsible administrator, status history, administrative changes, audit events, and request IDs. | Generated when authentication, security controls, account-status administration, abuse prevention, or dispute handling operates. | Secure accounts; prevent abuse; investigate login and account-integrity events; administer account status; maintain a record of security and administrative actions; handle disputes. | VeloCare’s database and restricted administrative systems. Internal block reasons are not displayed in the user-facing app. | Account-linked login and status history is deleted with the account. Failed or unknown-account login records without a user ID are not automatically deleted. Some administrative audit records can remain after account deletion. No automatic time-based purge is currently configured for these database records. |
| Support communications | Selected support topic; user-written message; app version; build number; iOS/iPadOS name and version; general device type or localized model. | User-initiated email. The rider can review and edit the prepared message before sending it. | Answer support requests and troubleshoot the app. Anything the rider voluntarily adds is received by VeloCare. | Support recipient: dhibi.ywsf@gmail.com; the user’s email provider and Google/Gmail may independently process the message. | Normally no longer than 24 months after the last communication. It may be retained longer when reasonably necessary for an unresolved request, security investigation, legal obligation, or dispute. Users may request earlier deletion where applicable. |
| Operational, network, usage, and diagnostic data | Request method and endpoint path; response status; request duration; generated request ID; error code and redacted error context; rate-limit events and observed network address; and user IDs in certain authentication or operational events. | Automatically generated when the app and backend communicate or when security controls operate. | Operate, secure, rate-limit, troubleshoot, and improve service reliability. | VeloCare backend and its hosting/VPS provider. Rotated container logs currently use five 10 MB files per API container rather than a fixed time-based period. Provider-level access logs follow the hosting provider’s applicable retention practices. | Container logs rotate using five files of up to 10 MB per API container. The repository does not define a fixed time-based log-retention period. Hosting or proxy providers may keep separate access logs under their own policies. These rotating logs are separate from persisted login-security and audit database records. |
Authentication details
- Apple can provide a provider-specific identifier, name, and email. The rider may choose Apple’s private email relay.
- VeloCare’s backend extracts the Google provider identifier, email, verification status, name, and client/audience information from the Google identity token. It does not receive a phone number or coarse location from that token.
- The bundled Google Sign-In 9.2.0 SDK privacy manifest separately declares that the SDK or Google may process name, email address, phone number, other data types, coarse location, user ID, device ID, and other usage data for app functionality and/or analytics, linked to the user and not used for tracking. This SDK-level disclosure is broader than the identity-token fields received by VeloCare’s backend.
- VeloCare does not receive the user’s Apple or Google password.
- VeloCare’s server creates its own bearer session credential after successful authentication. The native session token is stored in the iOS Keychain with device-only protection.
- Apple authorization and identity tokens and Google identity tokens are transmitted for authentication and verification. The backend may retain an encrypted Apple refresh token when required to support provider revocation during account deletion.
- The current VeloCare iOS app exposes only Apple and Google sign-in. Although the repository contains backend support for local email credentials for possible future or other clients, this policy does not tell iOS users that email/password sign-in is available. If that feature is publicly launched, this policy must be updated before launch to cover password hashes, verification/reset tokens, and transactional email delivery.
- VeloCare does not request Google Contacts, Gmail, Drive, Calendar, or other extended Google API scopes.
Product analytics limits
Before authentication, product events are initially unauthenticated and associated with a random installation UUID. They are pseudonymous rather than permanently anonymous because the backend can later link earlier events from that installation to an authenticated VeloCare account.
The telemetry payload is designed not to contain names, email addresses, phone numbers, precise location, ride routes, bicycle photographs, report content, maintenance notes, authentication credentials, session or provider tokens, purchase receipts, transaction identifiers, or arbitrary free-form text. VeloCare does not use IDFA, IDFV, hardware-derived identifiers, device fingerprinting, or AppTrackingTransparency for this telemetry.
The server rejects incoming events more than 30 days old. This is an ingestion rule, not a promise that stored events are deleted after 30 days.
Health and Fitness information
VeloCare’s “Health & Fitness” information means riding preferences and ride-derived activity measurements such as distance, duration, and speed. The current app does not read from or write to Apple Health or HealthKit.
Location flow
- VeloCare requests precise location permission through iOS. It does not contain a separate user-facing coarse-location feature.
- Location collection begins only when the rider starts a ride. It may continue for that active ride while the screen is locked or another app is open.
- Collection stops when the ride is finished or discarded. An active ride is held in a protected local draft for recovery.
- The route is sent to VeloCare’s server only after the rider finishes and chooses to save the ride. A discarded draft is deleted rather than uploaded.
- VeloCare does not continuously track the rider outside a rider-started active ride. Some providers may independently infer approximate location from an IP address; that is technical/network data, not a separate VeloCare route feature.
05 · AI sharing
AI-assisted bicycle photo analysis
AI output is a limited visual-condition observation. It is not a mechanical inspection, safety certification, or confirmation that a bicycle is safe or roadworthy.
When a rider requests an AI-assisted report, VeloCare’s custom server sends the selected scan input to OpenRouter, an AI API gateway. OpenRouter routes the request to the downstream AI model provider selected in VeloCare’s server configuration. The provider or model can change without an app update. OpenRouter’s and the downstream provider’s own retention and data-use rules apply separately from VeloCare’s retention.
What a complete-bike scan sends
- The selected drivetrain-side, front, and rear JPEG photographs.
- Capture-view labels.
- Bicycle type, brake type, brand and model, model year, and bicycle name.
- Drivetrain, frame material, and wheel size when available.
- Last-service range and bicycle lifetime distance.
What a focused-area scan sends
- The selected focused-area JPEG and its capture-view label.
- Focused scans do not send the full bicycle profile.
What the AI-analysis request is not designed to include
- The user’s account password.
- Authentication or session tokens.
- The account email address.
- The account profile name.
- The VeloCare account UUID.
- Precise location.
- Recorded ride routes.
Consent and withdrawal
Before the first production AI upload for an account and consent-policy version, the app presents an AI-sharing disclosure. The rider chooses Allow and analyze or Not now. Choosing “Not now” does not upload the selected photographs. The decision is remembered locally on the device for the relevant VeloCare account and disclosure version.
The rider can revoke future AI-analysis permission from Profile → Privacy & data. Revocation stops future analysis until permission is granted again. It does not automatically delete existing reports, retained report images, purchases, bicycles, or rides. A rider can separately delete an existing report or delete the account.
Separate AI retention layers
Raw/staging scan media is removed according to the retention window configured on VeloCare’s production server. Canceled images are eligible for earlier deletion. Failed deletion attempts may be queued and retried.
VeloCare creates private report-image derivatives associated with saved reports. These are separate from raw/staging uploads and follow their own production retention window. They may be removed earlier when the report or account is deleted. Report text, findings, and maintenance information may remain after images expire until the applicable report, bicycle, or account is deleted.
OpenRouter’s handling depends on its current policy and VeloCare’s production prompt-logging and data-use settings. VeloCare does not claim that Zero Data Retention is active. OpenRouter may retain request metadata such as token counts and latency.
The model provider selected through OpenRouter may separately process and retain scan inputs and outputs under its own terms, eligibility rules, and active settings. VeloCare’s media-retention windows do not control OpenRouter’s or the downstream provider’s retention.
Provider information: OpenRouter data collection, OpenRouter ZDR explanation, and OpenRouter Privacy Policy. The applicable downstream-provider notice depends on the provider configured in production. Provider rules and account settings can change.
06 · Product records
Reports, findings, and care history
VeloCare stores the resulting structured report, findings, limitations, related maintenance recommendations, scan status, and related metadata so the rider can review the report and maintain bicycle-care history. These records are linked to the account and retained until the applicable report, bicycle, or account is deleted, subject to separate report-image expiration.
VeloCare may store provider request metadata such as model/provider identifiers, token counts, latency, response identifiers, provider status, and provider cost to operate quotas, troubleshoot failures, and monitor service quality. These records are not a substitute for an AI provider’s own retention policy.
A report cannot reliably assess hidden or internal condition, torque, pressure, bearing condition, cable tension, or damage not visible in the photographs. It does not prove that a bicycle is safe, roadworthy, or ready to ride. Riders should use the bicycle and component manuals and a qualified bicycle mechanic for safety-critical concerns.
07 · Purchases
VeloCare Pro and subscriptions
VeloCare Pro purchases are processed through Apple’s App Store. RevenueCat manages subscription offerings, entitlement verification, restoration, and lifecycle synchronization. VeloCare does not receive or store the user’s payment-card number.
RevenueCat may process a generated anonymous customer ID before authentication when plans are loaded, the stable VeloCare account/customer UUID after authentication, Apple receipt and purchase history, product identifier and subscription status, renewal and expiration data, refund and revocation events, billing-issue and environment information, last-seen and technical information such as device type and operating system, and network information described by RevenueCat’s policy.
VeloCare’s server stores RevenueCat customer/app-user identifiers; product and provider subscription identifiers; access, entitlement, renewal, expiration, billing, environment, and store state; purchase-lifecycle and transaction records; amounts and currency and price, tax, or commission values in USD when supplied; alias and transfer relationships; webhook processing history; and scan-quota periods, consumption, reservations, denials, and adjustments. These records support app functionality and subscription lifecycle administration, not targeted advertising.
Deleting a VeloCare account does not cancel an App Store subscription. The rider must cancel or manage billing through Apple. Account deletion removes the active RevenueCat customer mapping, account entitlement, access grants, and account-linked subscription associations and queues RevenueCat customer erasure. Raw RevenueCat webhook-event and customer-alias history is not currently deleted by the local account-deletion transaction and has no automatic time-based purge. Apple and RevenueCat may independently retain records under their own policies.
RevenueCat Privacy Policy · Apple Privacy Policy · Apple subscription management
08 · Support
Support communications and diagnostics
Support email is user-initiated. The app prepares an email containing the selected support topic, the user-written message, VeloCare app version, build number, iOS/iPadOS name and version, and general device type or localized model. The rider can review or edit it before sending.
The automatic support block does not include scan photos, reports, precise location or routes, passwords, or authentication/session tokens. Anything the rider voluntarily adds to the message will be received by VeloCare.
Support recipient: dhibi.ywsf@gmail.com. Support emails will normally be retained for no longer than 24 months after the last communication, then deleted. They may be retained longer when reasonably necessary for an unresolved request, security investigation, legal obligation, or dispute. Users may request earlier deletion where applicable. The user’s email provider and Google/Gmail may independently process the message.
09 · Recipients
Service providers and data recipients
VeloCare shares information with the providers below only as needed for the described service functions. Each provider has its own privacy notice and may independently process information under its terms. Provider-specific retention, infrastructure, and international-processing details are governed by the applicable provider terms and controls.
| Provider | Role | Information involved | Provider notice |
|---|---|---|---|
| Apple | Sign in with Apple; App Store payments and subscription management; Core Location, MapKit, Photos, and notification platform functionality. | Identity data, transactions, location requests, photo-picker or system requests, and device/system information as applicable. | Apple Privacy Policy |
| Google Sign-In. | VeloCare’s backend receives the provider identifier, email, verification status, name, and client/audience information from the identity token—not phone number or coarse location. Separately, Google Sign-In 9.2.0’s SDK privacy manifest declares name, email, phone number, other data types, coarse location, user ID, device ID, and other usage data for app functionality and/or analytics, linked to the user and not used for tracking. VeloCare does not request Contacts, Gmail, Drive, Calendar, or other extended Google API scopes. | Google Privacy Policy | |
| RevenueCat | Subscription offerings, purchases, restoration, entitlement verification, lifecycle synchronization, and subscription analytics. | Customer/app-user IDs, Apple receipt and transaction data, product, entitlement and lifecycle data, aliases and transfer relationships, and technical information. | RevenueCat Privacy Policy |
| OpenRouter | AI API routing. | Selected scan photos, view labels, applicable bicycle details, prompts/results, and request metadata for a requested scan. | OpenRouter Privacy Policy |
| Downstream AI model provider | AI model processing selected through OpenRouter. | The scan inputs routed by OpenRouter and the resulting AI output, subject to the configured provider’s terms, data controls, and retention. | The applicable provider notice depends on the production model/provider configuration. |
| Google/Gmail | Support mailbox and voluntarily sent support content. | Support email contents and standard email metadata. | Google Privacy Policy |
| VeloCare hosting provider | Custom API hosting, private report media, and service logs. | Account and product data, uploaded media, requests, and operational logs as needed to host the service. | Processing follows the provider’s applicable privacy terms and the service arrangement with VeloCare. |
| VeloCare database provider | Account and product database. | Account, bicycle, ride, scan, report, maintenance, subscription, and operational records. | Processing follows the provider’s applicable privacy terms and the service arrangement with VeloCare. |
| Infrastructure backup provider, if configured | Backup storage used by the production infrastructure, if any. | Copies of database or media data according to the production backup configuration. | The provider’s applicable privacy terms and service arrangement govern its processing. |
| Resend, conditional backend feature | Transactional email for local credential verification or reset flows, only if that backend functionality is enabled or used by a client. | Email address, verification/reset messages, and delivery metadata for that feature. The current iOS app exposes only Apple and Google sign-in. | Resend Privacy Policy |
VeloCare uses these providers for the service functions described in this policy. Each provider’s processing is also governed by its own terms, settings, and privacy notice.
VeloCare may disclose information when legally required, to protect users or service security, or as part of a business transfer, subject to applicable notice and legal safeguards.
10 · Retention
How long information remains
Retention depends on the type of information and whether it is stored by VeloCare or processed independently by a provider. Deleting information from active VeloCare systems can occur before copies disappear from legitimate backups or external-provider systems.
| Information | VeloCare retention | Deletion or other trigger |
|---|---|---|
| Account identity and profile | Until account deletion, subject to lawful exceptions. | Account deletion or lawful retention requirement. |
| Onboarding and bicycle data | Until edited, bicycle deletion, or account deletion. | Rider edit, bicycle deletion, or account deletion. |
| Saved precise ride route | Until the ride or account is deleted. | Saved-ride deletion or account deletion. |
| Bicycle lifetime mileage | It is preserved after an individual ride is deleted and remains until the bicycle or account is deleted. | Bicycle deletion or account deletion. |
| Active local ride draft | Until upload, discard, sign-out/account cleanup, or recovery is no longer needed. | Ride completion, discard, cleanup, or stale-draft handling. |
| Raw/staging scan photos on VeloCare server | Until the configured production staging/media-retention window expires, or earlier deletion. Repository defaults do not establish the deployed production value. | Configured expiration, cancellation, report/account deletion, or deletion retry completion. |
| Local temporary scan files | Normally removed after use; stale files are cleaned within 24 hours and on applicable sign-out cleanup. | Use completion, sign-out cleanup, or stale-file cleanup. |
| Saved report-image derivatives | Until the configured production report-media-retention window expires, or earlier report/account deletion. Repository defaults do not establish the deployed production value. | Configured media expiration, report deletion, or account deletion. |
| Report text, findings, and scan metadata | Until report, bicycle, or account deletion. | Report deletion, bicycle deletion, or account deletion. |
| Maintenance tasks and notes | Until task, report, bicycle, or account deletion according to the task-source rules. | Task, report, bicycle, or account deletion. |
| Active account-linked subscription records and quota | Until account deletion or earlier adjustment. RevenueCat may retain provider-controlled records separately. | Account deletion, provider erasure process, or product lifecycle update. |
| Raw RevenueCat webhook and alias history | No automatic time-based deletion period is currently configured. These records are not currently removed by the local account-deletion transaction. | Manual removal, anonymization, or implementation of a documented retention process. |
| Raw account-linked product telemetry | No automatic time-based deletion period is currently configured. Retained until account deletion where the account-linked cascade applies, manual removal, anonymization, or implementation of a documented retention process. | Account deletion, manual removal, anonymization, or a future documented retention process. |
| Unlinked installation telemetry | No automatic time-based deletion period is currently configured. It normally becomes account-linked when the same installation sends an authenticated telemetry batch; otherwise it remains until manual removal, anonymization, or implementation of a documented retention process. | Account linking followed by account deletion, manual removal, anonymization, or a future documented retention process. |
| Anonymous aggregate analytics | May be retained longer or indefinitely only when the aggregate no longer reasonably identifies an individual, account, installation, or session. | Continued aggregation/anonymization or manual removal. |
| Login and security history | No automatic time-based deletion period is currently configured. Account-linked login events are deleted through the account cascade; failed or unknown-account events without a user ID do not have that cascade. | Account deletion where linked, manual removal, anonymization, or implementation of a documented retention process. |
| Account block/unblock and status history | No automatic time-based deletion period is currently configured. Account-linked status history is deleted with the account. | Account deletion, manual removal, anonymization, or implementation of a documented retention process. |
| Administrative audit history | No automatic time-based deletion period is currently configured. Some records can retain a target identifier, reason, changes, or request ID after account deletion because no account-deletion cascade applies. | Manual removal, anonymization, or implementation of a documented retention process. |
| Deletion receipts | No automatic time-based deletion period is currently configured. Receipts use an HMAC-based representation to record deletion completion without restoring the deleted account. | Manual removal, anonymization, or implementation of a documented retention process. |
| Completed media-deletion metadata | No automatic time-based deletion period is currently configured. Completed queue metadata may remain after the media itself is deleted. | Manual removal, anonymization, or implementation of a documented retention process. |
| AI-provider data | According to OpenRouter’s and the configured downstream provider’s policies and active account controls. VeloCare does not claim Zero Data Retention. | Provider policy and configured controls, which may change. |
| Session credential | Until expiration, invalidation, logout, or account deletion. | Session lifecycle or account deletion. |
| Account export on server | Generated transiently; no stored export archive. | Transient generation completes or fails. |
| Export file on device | Removed after sharing; abandoned files are cleaned within 24 hours. | Share completion or stale-file cleanup. |
| Support emails | Normally no longer than 24 months after the last communication, then deleted. Longer retention may apply for an unresolved request, security investigation, legal obligation, or dispute. Earlier deletion may be requested where applicable. | Last communication, resolution, legal obligation, security investigation, or dispute. |
| Application logs | Rotated across five files of up to 10 MB per API container; this capacity-based rotation does not establish a fixed time period. Hosting or proxy logs may follow separate provider retention. | Container rotation, provider log deletion, or other configured removal. |
| Backups | Backup copies, if created, may remain until they expire under the applicable backup schedule and may be removed later than active systems. | Backup expiration, deletion, and provider-specific lag. |
11 · Your choices
Controls and privacy rights
In-app controls
- Export: Profile → Privacy & data → Prepare data export.
- Edit: Edit the account name and rider preferences in Profile; edit bicycle data through the relevant app controls.
- Delete: Delete saved rides and saved reports through the relevant app controls.
- AI permission: Revoke future AI-analysis permission under Profile → Privacy & data.
- Device permissions: Disable camera, location, or notification permission through iOS Settings.
- Provider access: Manage Apple or Google sign-in access through the applicable provider account.
- Subscriptions: Manage or cancel subscriptions through Apple.
- Sessions: Sign out or sign out everywhere.
- Account: Permanently delete the VeloCare account in Profile.
What the export includes
The self-service export includes account and profile data; provider-link names and timestamps; bicycles; ride summaries and precise segmented routes; scan history; reports and findings; maintenance tasks and events; subscription status and quota information; and the device reminder preference.
It does not include raw telemetry; login-security history; administrative audit events; raw RevenueCat webhook history; raw scan photographs; AI prompts or provider payloads; credentials, tokens, secrets, or password hashes; signed URLs; internal logs; or other users’ information.
Information excluded from the self-service file may still be considered in response to a verified privacy request where access rights apply.
Privacy requests
Depending on where you live and how the law applies, you may have rights to access, correction, portability, deletion, restriction or objection, withdrawal of consent, complaint to a competent privacy authority, and an appeal where required by applicable law. VeloCare will not provide discriminatory treatment for exercising applicable privacy rights.
Send requests to dhibi.ywsf@gmail.com. VeloCare may need to verify your identity using information associated with your account before acting on a request. Responses will follow applicable legal deadlines; VeloCare will not promise a deadline that the operator cannot meet.
12 · Account deletion
Permanent deletion
Before deletion, the rider confirms the account email. The account-deletion transaction deletes or cascades most account-linked active product data, including the account and profile; authentication-provider and local-credential records; onboarding profile; bicycles; rides and precise routes; ride highlights and share recipes; scans; reports, findings, and maintenance information; account-linked telemetry and login events; account-linked entitlement history; and current subscription/customer associations.
Media files are placed into a durable deletion queue and removed by a retrying worker. Where applicable, Apple token revocation and RevenueCat customer erasure are also queued and can be retried after the local account is deleted. Temporary encrypted provider material is retained only as needed to complete that cleanup and is purged after successful completion.
Deletion of the active account does not immediately remove every associated or previously generated record. Unlinked telemetry; unlinked login-security events; raw RevenueCat webhook and alias history; some administrative audit records; HMAC-based deletion-completion receipts; completed media-deletion queue metadata; anonymous daily aggregate metrics; and provider-controlled or backup copies, if they exist, may remain under the retention criteria above.
Account deletion does not cancel an App Store subscription. Apple and other providers may independently retain records under their own policies. Account deletion is irreversible.
13 · Protection
Security
VeloCare uses administrative and technical safeguards intended to reduce unauthorized access, disclosure, alteration, and loss, including:
- HTTPS/TLS between the app and VeloCare’s API.
- Authenticated, owner-scoped server endpoints.
- Native session token storage in the iOS Keychain with device-only protection.
- Protected local files for ride drafts, scan photos, report-media cache, and exports.
- Temporary exports and report caches excluded from backups where implemented.
- Private server media directories and authenticated media access.
- Encryption of retained Apple refresh tokens.
- Redaction of sensitive logging fields.
- Rate limiting and session invalidation.
- Restricted server-side vendor credentials.
No method of electronic transmission or storage is completely secure, but VeloCare uses administrative and technical safeguards intended to reduce unauthorized access, disclosure, alteration, and loss.
These measures reduce risk but cannot guarantee that electronic transmission or storage will always be secure.
14 · Geography
International transfers
VeloCare’s controller is established in Tunisia. Some providers, including OpenRouter, the configured downstream AI model provider, RevenueCat, Apple, Google, and support or email providers, may process information in the United States or other countries. Privacy laws may differ from the laws in your country.
Transfers are handled under the applicable provider terms and privacy controls. VeloCare does not claim a specific transfer mechanism or adequacy protection where it has not been separately verified.
15 · Age
Children
VeloCare is not directed to children. VeloCare does not knowingly collect personal data from children without any legally required parental authorization. A parent or guardian may contact dhibi.ywsf@gmail.com to request deletion, subject to identity and authority verification.
16 · Use limits
Sale, advertising, tracking, and automated decisions
- VeloCare does not sell personal data.
- VeloCare does not share personal data for cross-context behavioral advertising.
- VeloCare does not display targeted advertising.
- VeloCare does not use IDFA, IDFV, hardware-derived identifiers, device fingerprinting, or App Tracking Transparency for tracking.
- VeloCare uses limited first-party product analytics for the seven event types described above. It does not use that telemetry for third-party advertising.
- VeloCare does not use Firebase Analytics, PostHog, Mixpanel, Amplitude, Sentry, or another dedicated third-party analytics SDK.
- Google Sign-In and RevenueCat independently process information for their disclosed authentication and subscription-service functions.
- VeloCare does not use scan photos or reports to train its own AI model.
- AI report generation is automated processing requested by the rider. It is informational bicycle-maintenance content and does not make legal, employment, credit, insurance, medical, or similarly significant decisions.
Provider training and retention are controlled by provider policies and the active production account settings. VeloCare does not make an absolute provider-training or “no review” promise.
17 · Public website
Website data
The public RideKept/VeloCare website is intended to be a static, public site without sign-in, advertising, analytics, tracking pixels, or nonessential cookies on this policy page. The current project may contain site-wide advertising configuration for other pages; if advertising, analytics, cookies, contact forms, or tracking are enabled, those practices must be disclosed separately and any legally required consent must be implemented before launch.
Links to Apple, Google, RevenueCat, OpenRouter, the configured downstream AI provider, and other providers take you to services governed by their own policies. A site visitor may contact the operator using the public support or contact address; the email provider may process that message.
18 · Updates
Changes to this policy
The “Last updated” date changes when this policy changes. Material changes may be communicated in the app, on the website, or by email where appropriate. If a material change affects AI data sharing or consent, VeloCare may increment the consent-policy version and request permission again.
- August 19, 2026: Added limited first-party telemetry; expanded authentication, security, administrative-audit, purchase, retention, export, and account-deletion disclosures; and made AI provider and media-retention descriptions depend on verified production configuration.
- August 16, 2026: Published the VeloCare-specific policy covering account, bicycle, ride, photo, AI-assisted report, subscription, support, provider, retention, security, and privacy-choice practices.
19 · Contact