API roadmap

What Avelok will expose to technical partners, in what order, and which guarantees come with each surface. Honest about what isn't ready yet.

We don't have a public API today. This page exists because partners keep asking the same questions ("can I read my club's data?", "can I push attendance from my booking system?") and we'd rather be specific about timing than vague.

Today (no API)

If you're a partner today, your integration options are:

  • CSV export of members, attendance, package consumption from Club OS
  • iCal feed for read-only schedule subscription
  • Stripe webhook passthrough for payment events (because Avelok uses Stripe directly; you can subscribe to your own Stripe events)
  • Email alerts for retention dashboards

That's the surface area. Everything else is manual.

Q3 2026 — Read API (private beta)

First real API surface, scoped tightly:

GET /v1/members

Roster snapshot. Pagination, filters by tier and coach.

GET /v1/sessions

Time-window query of sessions. Returns coach, player(s), duration, package consumed. Does NOT return AI conversations or private notes.

GET /v1/packages

Active packages with consumption status.

GET /v1/retention

Cohort retention numbers, same as the Club OS dashboard, in JSON.

Auth: API tokens, scoped to a single Club OS workspace, per-token rate limit of 30 req/min. No OAuth in this phase.

Private beta means: 5 partner clubs, signed agreement, weekly feedback call. Apply via partnerships email.

Q1 2027 — Write API + Webhooks

Once the read API has been stable for a quarter:

POST /v1/sessions

Push attendance from a partner booking system. Validates the coach + player + package, refuses overruns.

POST /v1/members

Provision new members from a partner CRM.

Webhooks

member.created, member.churn_risk, session.completed, package.expired. Signed payloads (HMAC SHA-256), retries with exponential backoff up to 24h.

The hardest surface, because it touches the memory:

GET /v1/athletes/:id/profile

Public-face memory: current strengths, current focus area. Requires the athlete's explicit per-token consent and is auditable in Settings → Data.

GET /v1/athletes/:id/timeline

Sessions and matches the athlete chose to expose. Same consent gate.

POST /v1/athletes/:id/note

Append a note from a sanctioned external source (a federation event result, a physio assessment). Note is tagged with origin and is editable by the athlete.

There will not be a "give me everything about athlete X" endpoint, even with consent. Partner integrations get deliberately narrow scopes.

What we won't ever expose

A short list, so partners can plan around it:

  • AI chat conversations, in any form, even with consent.
  • Other athletes' data alongside any single athlete's data.
  • Bulk export of training notes for ML training by external parties.
  • Anything scoped above a single workspace (no "give me all sessions across the platform" endpoints).

Stability guarantees

When the read API ships in Q3 2026, the contract is:

  • Versioned URL prefix (/v1/...). v1 is supported for a minimum of 24 months after a v2 ships.
  • Breaking changes go through a 6-month deprecation window with email notice.
  • Schema additions (new fields) are non-breaking and may ship anytime.
  • Sandbox environment with synthetic data, separate from production tokens.

Trying it before it's public

If you're a serious partner and want to influence the shape of the API before private beta, the right path is:

  1. Read SaaS strategy so you know what we're building (and not building).
  2. Email partnerships@avelok.com with: who you are, what you'd integrate, which 3 endpoints would be highest leverage for you.
  3. We reply with whether your use case fits the roadmap, and if so, schedule a 30-minute scoping call.

Most partners self-select out of this — that's fine. We'd rather have 5 deep integrations than 50 shallow ones.

What's next