Skip to content
WearLink

Product

IntegrationsData typesUse casesNutrition APIProvider statusSecurityPricing

Developers

DocumentationWebhook eventsAPI referenceSystem status

Resources

GuidesCompareAboutContact
Sign inGet started

Legal

Privacy Policy

Last updated

This policy explains what WearLink collects, where it is held, who else touches it and what rights you have over it. It covers developer accounts (the customers who integrate the API) and the end-users whose health data flows through the platform on a developer's behalf.

Roles

For end-user health data, the developer who integrates WearLink decides what is collected and why; WearLink processes it on that developer’s instructions. For developer account data, WearLink decides the purposes itself. Where a law uses the terms controller and processor, or data fiduciary and data processor, those are the roles we mean.

Developer accounts

When you sign up we collect your name, email address, a hashed password and operational metadata (IP address, user agent, timestamps). We use this to authenticate you, secure the account, bill you and tell you about changes to the service. Account data is retained while the account is active and for a limited period afterwards for dispute resolution and tax records.

API keys are stored only as SHA-256 hashes. The raw key is shown once at creation and cannot be recovered by us. Two-factor authentication secrets, where enabled, are encrypted at the application layer before storage.

End-user health data

We store what the developer’s integration asks us to store: provider connection tokens, the raw records fetched from connected wearables and health apps, normalised derivatives of those records (summaries, time series, scores), and meal photos and nutrition logs where the developer uses those features. We do not sell end-user data, we do not use it to train models, and we do not share it with anyone except the subprocessors listed below.

Consent to read a wearable is collected from the end-user by the provider at connection time, through the provider’s own authorisation screen. The developer is responsible for obtaining any additional consent its product or jurisdiction requires.

Meal photos have EXIF metadata, including GPS coordinates, stripped and are re-encoded before storage. Photo recognition is performed by a subprocessor listed below; the image is sent for analysis and the returned nutrition estimate is stored alongside it.

Where data is hosted

The application and database run on isolated single-tenant virtual infrastructure operated by our infrastructure partner in Malaysia (Asia-Pacific). Asynchronous export files are written to a self-hosted, S3-compatible object store on a separate host reachable only from the application. WearLink does not currently offer a choice of hosting region on self-serve plans; region options can be discussed for Enterprise deployments.

Because the hosting region is Malaysia, health data on residents of other countries, including India, the EU and the United States, is stored outside those countries. Developers subject to a data-localisation or cross-border transfer obligation should assess that before integrating; the DPDP guide discusses the Indian case specifically.

Subprocessors

  • Infrastructure hosting partner (Malaysia): single-tenant compute and storage.
  • Svix: signed outbound webhook delivery and retries.
  • Razorpay: payment processing. Card details never reach WearLink.
  • Anthropic (United States): meal-photo nutrition recognition. Images are sent for analysis only.
  • Google Workspace: transactional email delivery from our own domain.

We will update this list before adding a subprocessor that receives end-user data.

Security

All traffic uses TLS 1.2 or later with HSTS. API keys are hashed; sessions use short-lived access tokens with refresh-token rotation and server-side revocation; every query is scoped to the owning developer; account, key, billing and export actions are written to an audit log that can be exported. Provider OAuth tokens are encrypted at the application layer (Fernet) before they are written to the database on the single-tenant host, with database access restricted to the application. The full statement of what is and is not in place, mapped to ISO/IEC 27001 control families, is on the security page. WearLink holds no SOC 2, ISO 27001 or HIPAA attestation.

Retention and deletion

End-user data is retained while the end-user record exists. Meal photos are deleted from storage after 90 days and asynchronous export files after 7 days. A developer can export an end-user’s account, connections, data sources, events, sleep and workout details, time series, scores and nutrition logs with a single request (provider credentials are never included), and can delete an end-user, which hard-deletes their database records and revokes provider connections. Audit-log entries are retained for as long as the developer account exists. Backups are retained on a rolling basis and purged on their own schedule after a deletion; we do not selectively edit backups.

End-users exercise access and erasure rights through the developer whose product they use. The developer’s interface uses our per-user export and deletion endpoints for that purpose.

Meal photos

When an end-user logs a meal by photo, the image is re-encoded (location and other EXIF metadata removed), analysed by Anthropic, and stored for up to 90 days. When the automated estimate is uncertain, a WearLink team member may review the photo to correct it.

Your rights under India’s DPDP Act

Developers (WearLink is the data fiduciary for your account data) can access and correct their details in the dashboard, withdraw consent by deleting the account from Settings, and ask us anything about their data at hello@wearlink.io.

End-users of an app built on WearLink should contact that app first: the developer is the data fiduciary and WearLink processes the data on its behalf. Withdrawing consent is done by disconnecting the device in that app, which stops all further collection (the app can also erase everything already collected from that device at the same time); asking the app to delete your account removes your records from WearLink as described above. If the app does not respond, write to us and we will pass the request on and follow it up.

Grievances: email hello@wearlink.io with the subject “Grievance”. We acknowledge within 7 days and resolve within the period the DPDP Rules allow. If you are not satisfied, you may complain to the Data Protection Board of India. You may also nominate another person to exercise these rights on your behalf if you die or become unable to act; tell us who in writing.

Children: WearLink is built for developers and is not directed at anyone under 18. A developer whose app serves children must obtain verifiable parental consent before connecting a child’s device.

Cookies

The marketing site sets no analytics or advertising cookies. The developer dashboard uses first-party storage for authentication and session state only.

Changes

We will post changes to this policy on this page with a new date, and email developer accounts about changes that materially affect end-user data handling.

Contact

Privacy questions and requests: hello@wearlink.io. For security reports, use the address in /.well-known/security.txt.