Privacy Policy
Last updated: August 3, 2026
Version: 2026-08-03
Effective: August 3, 2026
1. Controller and scope
The controller is Roberto Diaz, a self-employed sole trader established in Spain (Spanish tax ID 71655922C), with a professional address at Calle Vázquez de Mella 75, 33012 Oviedo, Asturias, Spain.
- Privacy and rights requests: [email protected].
- General and legal contact: [email protected].
Verxion has not currently appointed a Data Protection Officer. Privacy enquiries and rights requests may be sent to the address above. Whether appointment is mandatory under GDPR Article 37 remains subject to a documented legal assessment and will be revisited if the scale, nature, or monitoring changes.
This Policy covers verxion.ai, the web and mobile apps, API, MCP servers, widgets, coaching, waitlist, support, and connected apps operated by Verxion. Social publishing and payments are not currently enabled; those sections apply only if the features are activated after the corresponding review and update. Third-party products you choose—such as an identity provider, AI model, or MCP client—have their own policies where they act as independent controllers.
2. Data we process
Depending on the features you use, we process:
- Account, authentication, and legal documents: email, name, provider image, Apple/Google identifiers, sessions, tokens, and verification state. New explicit records distinguish accepted Terms from acknowledged Privacy information and include document version and hash, language, surface, evidence identifier, and time; historical legacy records may contain only version, time, and source. Specific consents have their own records. Email/password access may exceptionally be enabled for authorised app-store reviewers; only a password hash is then stored.
- Profile and onboarding: username, account type, date of birth, sex or gender, height, measurement system, experience, goals, preferences, language, theme, referral source, and answers about working as or with a coach.
- Health, training, and wellbeing: routines, programmes, mesocycles, sessions, sets, loads, repetitions, cardio, steps, pauses, sleep, energy, stress, motivation, feelings, notes, declared injury or illness, availability, and time off. If you connect Apple Health/HealthKit, Verxion reads only body mass, daily step totals, and workout records (type, date, duration and, where available, distance and active energy). A device-level iOS authorization and a separate account-scoped metric choice are both required. HealthKit sample/workout identifiers and deletion markers are used to de-duplicate and reflect changes.
- Nutrition: plans, meals, recipes, foods, water, supplements, macros, adherence, and analytics.
- Measurements and images: weight, perimeters, body composition and progress, tracking or projection images, avatars, and exercise-instruction images; plus type, size, path, thumbnail, and linked-video metadata.
- Conversations and AI: titles, messages, replies, summaries, message parts, tool results, attachment metadata, selected model/provider, token usage, estimated cost, usage caps, and finish state. When you confirm an image or PDF, its bytes are sent inline with that turn through Verxion’s harness to the selected provider; the stored conversation keeps metadata/a breadcrumb, not those inline bytes. Compatible spreadsheets are converted to text/Markdown and that extracted content persists as part of the message. There is no separate file-upload service. BYOK keys transit the request and must not be persisted or logged by Verxion.
- Coaching: coach profile, relationships and invitations, scopes, assignments, library, measurements, monitoring, and coach notes about clients.
- Social: athlete profile, bio, avatar, tags, visibility, showcase metrics, follows, requests, blocks, mutes, feed, and profile views. A hash of an IP address may be used to deduplicate views.
- API, OAuth, and MCP: API-key names and hashes, prefixes, usage, OAuth clients, redirect URIs, scopes, tokens, consents, idempotency, executed tools, and access audits.
- Analytics and diagnostics: if you choose to allow PostHog, it receives a provider-generated pseudonymous identifier, product events from a closed catalogue, and bounded enum, boolean, count, or timing properties such as sign-in provider, language, onboarding progress, and non-content interaction state. It does not receive email, name, free text, gender, date of birth, goals, experience, measurement system, or health, training, or nutrition events. Native analytics does not identify the account. Autocapture, automatic page views, lifecycle events, automatic exception capture, and session recording are disabled where supported by the relevant SDK. Sentry separately processes PII-filtered errors, traces, and performance from web, server, and mobile for security and diagnostics.
- Communications and feedback: email, communication preferences, deliveries, bounces, waitlist status, feedback category and free text, and support messages.
- Billing, if enabled: store, purchase or RevenueCat identifiers, product, entitlement, renewal, price, currency, issues, and subscription events.
- Technical and security: request ID, timestamps, rate-limit state, IP address or hash where needed, user agent, security events, deletion/export records, and minimised operational logs.
- Mobile device storage and surfaces: authentication material, a BYOK provider key, HealthKit sync preferences and opaque cursors, onboarding drafts, analytics choice, interface preferences, local timers and notification identifiers may be stored on the device. Secrets and selected account-bound values use iOS Keychain-backed SecureStore; other device utilities may use local app storage. Read-only widget snapshots are copied to the iOS App Group so WidgetKit can render today’s, nutrition, training and consistency summaries. Local notifications and Live Activities may show reminders, timer/session state or that an AI reply is ready on system surfaces according to your iOS settings.
Some data reveals or permits inference about health and is special-category data under GDPR Article 9. Selected sensitive fields also use application-level encryption with a per-user key wrapped by AWS KMS in eu-north-1; infrastructure providers also apply transport and storage encryption. Encryption does not make personal data anonymous.
3. Purposes and legal bases
| Purpose | GDPR Article 6 basis | Additional health-data condition |
|---|---|---|
| Account creation, authentication, onboarding, and requested service delivery | Art. 6(1)(b), contract | Art. 9(2)(a), explicit consent where health data is involved |
| Training, nutrition, measurement, wellbeing, time-off, and image tracking | Art. 6(1)(b) | Art. 9(2)(a), explicit consent |
| Conversation storage and assistant, tool, and summary execution | Art. 6(1)(b) | Art. 9(2)(a) where content contains or infers health data |
| User-selected MCP, OAuth, API, and connected-app access | Art. 6(1)(b); Art. 6(1)(f) for security and auditing | Art. 9(2)(a) before exposing health data within an authorised scope |
| Coaching within an active relationship and granted scopes | Art. 6(1)(b) | Client’s Art. 9(2)(a) explicit consent for health data |
| Optional public profile and social features | Art. 6(1)(a), consent; Art. 6(1)(f) for abuse prevention | Art. 9(2)(e) only for data the user manifestly makes public; otherwise Art. 9(2)(a) |
| Optional PostHog product analytics | Art. 6(1)(a), consent | Art. 9(2)(a) if an event or attribute reveals or permits health inference |
| Diagnostics, security, fraud prevention, rate limiting, and auditing | Art. 6(1)(f), legitimate interest in protecting users and systems; Art. 6(1)(c) where legally required | Health content is minimised and excluded; where indispensable, Art. 9(2)(f) for claims or Art. 9(2)(a), as applicable |
| Transactional email and support | Art. 6(1)(b); Art. 6(1)(f) for handling requests | Health data is not requested; if volunteered, processing is limited to the request under explicit Art. 9(2)(a) initiative or Art. 9(2)(f) where needed for a claim |
| Waitlist and promotional messages | Art. 6(1)(a), consent, revocable in each message | Health data is not requested |
| Billing, purchases, and accounting | Art. 6(1)(b) and Art. 6(1)(c) | Health data is not requested |
| Rights, compliance, consent evidence, and legal claims | Art. 6(1)(c) and Art. 6(1)(f) | Art. 9(2)(f) where necessary |
Security interests include preventing unauthorised access, investigating incidents, preserving integrity, limiting abuse, and defending claims. You may ask about the balancing assessment and object; we will consider your circumstances.
Health consent is specific, informed, versioned, and withdrawable. Withdrawal does not affect earlier processing but stops new processing based on it and may disable incompatible features. Merely accepting this Policy is not that consent.
4. AI, MCP, and automated decisions
Verxion does not make solely automated decisions producing legal or similarly significant effects within GDPR Article 22.
There are two main flows:
- Your selected MCP client. The client calls Verxion within OAuth scopes. Its provider processes received data under its own agreement and normally as an independent controller.
- Verxion’s BYOK assistant. The message and context transit the EEA-hosted Verxion harness and are sent to your selected provider—OpenAI, Anthropic, Google, or OpenRouter—using your own key. Verxion stores the encrypted conversation under this Policy but does not persist the BYOK key or train its own models on the content. OpenRouter may route to another provider; Verxion requests no-training and zero-retention routing where supported by the API.
The interface informs you, no later than the start of the interaction, that you are interacting with AI and displays the applicable provider/model and context. You must expressly confirm before an attachment is sent. Outputs are reviewable suggestions, not diagnosis or professional instructions. Verxion does not currently publish AI replies to a public surface on your behalf; any future publishing or generation feature subject to marking under Regulation (EU) 2024/1689 will require technical and legal review before activation.
If web search is enabled, necessary query text may reach the BYOK provider’s search partner. We will not enable LLM credits using a Verxion-owned key without reviewing roles, executing the applicable DPA, and updating this Policy.
5. Data sources
We obtain data directly from you, your device and use, Apple or Google during sign-in, authorised apps or MCP clients, and public providers queried through a feature. If you opt in to Apple Health, HealthKit on your device is the source of the samples described above. Verxion does not read them before both device authorization and the current account’s explicit metric choice permit it, and imported history is limited to the period from your Verxion registration. A coach may contribute assignments, notes, or measurements; other users may generate interactions only if the social surface is later enabled. App stores may provide distribution or review information; billing events apply only if payments are enabled later.
Where data comes from another source and GDPR Article 14 applies, we provide required information within the statutory period unless a valid exception applies.
6. Recipients and roles
We do not sell personal data or use it for third-party behavioural advertising.
Processors that may act on Verxion instructions include Railway, AWS, Sentry, Upstash, Resend, Vercel, Cloudflare and, only after a current persisted choice to allow optional analytics, PostHog. The current list, purpose, region, transfer mechanism, and contractual links appear on the Sub-processors page.
The following normally act as independent controllers for their own purposes: Apple and Google for sign-in; BYOK providers and MCP clients selected by you; OpenFoodFacts; YouTube, Vimeo, TikTok, or Instagram when resolving a link; app stores; and coaches for their professional service where they determine their own purposes. Classification can vary by flow; if Verxion acts on documented instructions from a coach or organisation, an Article 28 agreement will be put in place.
7. International transfers
The code and current service configuration prioritise EEA regions: Railway is configured for EU West, AWS KMS for eu-north-1, Sentry for its EU region, Resend for Ireland, and PostHog for its EU endpoint. Upstash is configured in London. Actual project region, support access, subprocessors, and retention must be verified against each live account and executed agreement before release.
US entities such as Vercel, Resend, Cloudflare, PostHog, or particular providers may access data outside the EEA or use global subprocessors. The applicable adequacy decision, Standard Contractual Clauses, DPA, and supplementary measures depend on the executed provider terms and live configuration. Verxion must confirm and record that mechanism before enabling the relevant transfer; information on confirmed safeguards may be requested at [email protected].
Providers or clients you select under your own agreement may make their own international transfers; review their policies before authorising them.
8. Retention
| Category | Criterion or period |
|---|---|
| Account, profile, conversations, training, nutrition, measurements, coaching, and social content | While the account or content remains active; earlier if you delete it, consent withdrawal requires erasure, or the purpose ends |
| Expired OAuth tokens and sessions | Up to 30 days after expiry or revocation; session cookies have their own technical duration |
| Idempotency and rate-limit keys | Normally up to 24 hours |
| Access audits | 30 days, unless limited preservation is required for an incident or claim |
| Usage/cost events | While needed to show consumption, enforce caps, and resolve disputes; no longer than the account plus the applicable legal-claim period |
| Conversations | Until you delete the conversation or account; summaries change as context is compacted |
| Attachments sent to AI | Image/PDF bytes are transient for the confirmed turn and only their breadcrumb/metadata follows the conversation period. Text/Markdown extracted from a compatible spreadsheet persists inside the message until the conversation or account is deleted |
| Local onboarding draft | Up to 90 days, until completion/sign-out, or until the consent version changes, whichever occurs first |
| Mobile secrets and account-bound device data | Until the related provider/feature is disconnected, the account is signed out or deleted and local cleanup runs, or the app is removed; purely device-level language and sign-in-provider preferences may remain |
| Notification, Live Activity and widget state | Until it fires, is dismissed/cancelled, expires, is replaced by a newer snapshot, or account-bound device cleanup runs |
| Feedback | Pending feedback is deleted 730 days after submission; resolved feedback is deleted 730 days after resolution. An active legal hold defers deletion. Support requests are retained only as needed to handle them and defend claims |
| Sentry | According to the live project retention setting, which must be confirmed in the release record |
| Optional PostHog | Only while a current choice permits this purpose and under the live project retention setting. Withdrawal stops new events and resets local provider identity; deletion or expiry of historical data follows the confirmed provider setting and controls |
| Export download URLs | 15 minutes |
| Export job records | Terminal jobs become eligible for purge after 30 days through an idempotent retention task; expired artifacts are removed according to their expiry. The production scheduler cadence is verified in release operations |
| Terms, Privacy-information, consent, and deletion evidence | During the account and for up to six years afterwards where needed for compliance and defence, pseudonymised where possible. Expired deletion evidence is purged only after every associated external job is resolved |
| Waitlist/promotions | Until withdrawal, unsubscribe, campaign end, or two years without interaction |
| Invoices and accounting | Applicable tax, accounting, and claim periods |
| Dormant accounts | Target purge after 24 months’ inactivity and 30 days’ prior notice; if automation is unavailable, manual review applies the same criterion |
Account deletion performs a transactional database erasure and retains only limited evidence that must survive. External objects are deleted through retryable tasks; evidence purge is deferred and surfaced as an operational count while a job is pending or failed. Backups, if any, remain isolated, are not returned to production except for recovery, and rotate under the provider schedule; destroying the per-user key makes encrypted fields in earlier copies unreadable.
9. Rights
You may exercise rights to:
- access and obtain a copy;
- rectification;
- erasure;
- restriction;
- object to legitimate-interest processing;
- portability of provided data where applicable;
- withdraw any consent; and
- not be subject to solely automated decisions with legal or similar significant effects.
The app lets you download a JSON export, delete the account, withdraw health consent, reject or withdraw optional analytics, and revoke sessions/apps. For any right, email [email protected]. We may request proportionate information to verify identity. We normally respond within one month, extendable in statutory cases, and will explain an extension.
You may complain to the Spanish Data Protection Agency or the authority for your residence or the place of the alleged infringement.
10. Required data and consequences
Email, authentication, contractual acceptance, and fields marked as minimum onboarding data are needed to create and operate an account. Health consent is voluntary, but features processing those categories cannot work without it. Public profile, coaching, images, AI, optional analytics, and most logs are voluntary. Each screen should distinguish required and optional data.
11. Children
The service is not directed to children under 14. For ages 14 to 17, consent-based processing is valid only under Article 7 of Spain’s LOPDGDD and where the act does not legally require assistance from a representative. If an account lacks sufficient capacity or authority, we will restrict it and erase data where appropriate.
12. Security
Controls include scope separation, coach-client relationship checks, encryption in transit, sensitive-field encryption, per-user keys, PII filtering in observability, audit logs, rate limiting, revocation, and deletion checks. No measure eliminates all risk; report suspected incidents to [email protected].
13. Cookies and local storage
See the Cookie Policy for cookies, localStorage, sessionStorage, analytics, and controls. Storage or access that is not strictly necessary requires prior consent under Spanish LSSI rules.
On iOS, Keychain-backed SecureStore, app-local storage and the App Group support the mobile functions itemised in section 2. Widget, notification and Live Activity content can be visible on Home Screen, Lock Screen or Dynamic Island depending on your system privacy settings; you can disable those surfaces in iOS. HealthKit authorization is device-wide and managed in iOS Settings; signing out or switching off Verxion sync does not revoke it. Verxion’s account-scoped switches stop new imports, and the in-app withdrawal control records withdrawal of health-data consent and turns all metrics off. Neither action automatically deletes data already imported; you may exercise erasure or delete the account separately.
14. Changes
We publish the date and version of changes. Material changes receive proportionate notice. We may request renewed Terms acceptance, acknowledgement that updated Privacy information was received, or a new specific consent where required; acknowledging this Policy is not general consent to processing.