Skip to content
WearLink

Product

IntegrationsData typesUse casesNutrition APIProvider statusSecurityPricing

Developers

DocumentationWebhook eventsAPI referenceSystem status

Resources

GuidesCompareAboutContact
Sign inStart free

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.
  • Sentry: error and exception monitoring, with health data scrubbed from events.
  • Anthropic: 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; privileged actions are written to an append-only audit log that can be exported. Provider OAuth tokens are held in the database on the single-tenant host with database access restricted to the application; field-level encryption of those tokens is planned and is not claimed here. 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. A developer can export one end-user’s full normalised history with a single request and can delete an end-user, which removes stored 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.

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.