Skip to content
Developers

Walk15 Connect V1

Integration checklist

What to verify before going live, with links to the details.

Each item links to the section that explains it.

Readiness checklist

Credentials and authorization

  • Client secret in a secret manager, sent only in the Authorization: Basic header from your backend (client authentication)
  • No Walk15 credential or grant_id reaches a browser, mobile app, URL, log or analytics tool (credential storage)
  • redirect_uri byte-for-byte identical to the registered HTTPS callback (callback)
  • Fresh state and PKCE verifier per attempt, bound to the initiating user, single use, short expiry (authorization request)
  • grant_id attached to your user only after a successful exchange for the user who started the flow
  • Only the scopes your feature needs (scopes)
  • Callback handles both code and error=access_denied

Tokens

  • Tokens encrypted at rest in durable storage shared by all instances — losing a freshly rotated refresh token loses the connection
  • Refresh serialized per grant_id across all instances; new access and refresh tokens saved in one write (refresh)
  • A failed or uncertain refresh leads to reauthorization, never a resend (refresh failures)
  • Re-authorization replaces stored tokens and connection_version

Data

  • Windows of at most 31 dates, never before history_from (calendar dates)
  • Cursor pages fetched with the same from, to and limit; restart on invalid_cursor (pagination)
  • Snapshots replaced only after a complete, successful read; missing dates are "no data", not zero (corrections)
  • distance_meters treated as metres; recorded clocks stored unzoned (timestamps)

Webhooks (if used)

  • Signature and ±300 s timestamp verified on the raw body; server clock synchronized (signature verification)
  • Event stored with a unique constraint on id before a 2xx within 5 s; 503 for temporary failures (receiver)
  • Data fetched asynchronously; connection_version compared before acting (processing)
  • Secret rotation procedure agreed with Walk15 (secret rotation)

Operations

  • Retry-After applied to your whole worker pool; concurrency bounded; polling spread over time (rate limits)
  • Unlinking in your product calls the disconnect endpoint
  • Logs keep status codes and X-Request-ID, never credentials or activity values
  • Support contact with Walk15 established