Walk15 Connect V1 · Developer documentation
Connect with Walk15
Let Walk15 users share their daily steps and cycling with your product — with explicit consent, scoped OAuth access and optional signed webhooks.
Walk15 Connect lets an approved business read selected Walk15 activity data for its users' existing Walk15 accounts, with each user's explicit consent. It is OAuth 2.0 with PKCE: your backend receives scoped, rotating credentials for every connected user, then polls the activity endpoints or reacts to optional signed webhooks.
Your app or website
User starts the connection
Browser redirectWalk15 sign-in & consent
Existing Walk15 account, all-or-nothing approval
Your backend
Holds client secret and tokens
OAuth token + activity APIWalk15 Connect API
Scoped, rate-limited reads
Your webhook receiver
Optional, durable inbox
Signed notificationsWalk15 webhook sender
At-least-once, no activity values
Walk15 users record activity in the Walk15 app. Connect exposes only the authorized Walk15 daily totals and cycling records — never raw device or wearable-provider data.
Who it is for
Companies whose product benefits from their users' Walk15 activity — for example wellbeing, rewards, insurance, sports retail or employee engagement — and that run a backend to hold every credential.
Connect is not a self-service API: there is no developer sign-up, API-key console, public pricing or public sandbox.
How approval works
Walk15 reviews and provisions every customer manually. During onboarding Walk15 agrees with you:
| Item | What it is used for |
|---|---|
| Company display name, purpose text and privacy policy link | Shown to users on the Walk15 consent screen |
| Scopes your product needs | Your customer-level scope allowance; users can only be asked for these |
| One exact HTTPS callback URL | The only redirect_uri Walk15 will accept for your client |
| Expected traffic | Your technical rate policy |
| Optional webhook URL | Where signed notifications are delivered |
You then receive a client ID (a UUID) and a client secret through a secure channel. Credentials are issued per environment.
Data available
| Scope | Endpoint | Data |
|---|---|---|
daily_steps:read | GET …/daily-activity | Adjusted Walk15 daily step totals |
cycling_daily:read | GET …/cycling-daily | Daily cycling distance in metres |
cycling_activities:read | GET …/cycling-activities | Individual cycling activities, paginated |
All data is Walk15's own recorded data (source: "walk15"). Connect exposes no wearable-provider identity, device identifiers, raw sensor data or profile data — not even the user's email or Walk15 user ID. You only receive a pairwise grant_id. See Activity data.
How consent works
- Your backend sends the user's browser to Walk15 with the scopes you need.
- The user signs in to an existing Walk15 account with a one-time code sent by email. Connect never creates accounts.
- The consent screen shows your company, purpose, privacy policy, every requested dataset and the date access starts.
- The user approves all requested scopes or cancels.
Access is forward-only: from the user's authorization calendar day (the whole day) onward. A connection has no fixed expiry while you keep refreshing it; the user can disconnect at any time in the Walk15 app.
Polling and webhooks
Your backend reads activity snapshots with a short-lived access token, in windows of up to 31 dates. Optionally, Walk15 sends signed webhooks — connection.authorized, connection.revoked and activity.updated — that say which connection (and date) changed, never the data itself. All reads, polled or webhook-driven, share your rate policy.
What Connect V1 does not include
- Self-service registration, API-key management, billing or subscriptions.
- Historical backfill before the authorization day.
- Incremental consent — changing scopes requires disconnecting and reconnecting.
- OpenID Connect, ID tokens or user profile data.
- Direct wearable-provider synchronization or provider provenance.
- Sleep, heart-rate or body metrics.
Next steps
- Follow Getting started for an end-to-end integration walkthrough.
- Read OAuth and PKCE before implementing token storage.
- Keep the API reference open while you build. A machine-readable OpenAPI document covers the backend HTTP endpoints.