Getting Started
Vytal is the operating system for fitness businesses. One API powers four
surfaces: the public marketing site, the staff backoffice, the athlete portal,
and the integrations that read and write bookings, memberships, results, and
billing.
The one rule worth knowing up frontEvery request carries an organization API key, and every call is scoped to
that key's gym. Cross-tenant access is impossible by design.
The surfaces
| Surface | Where | For |
|---|---|---|
| Public site | vytal.fit | Marketing, schedules, sign-up |
| proVytal | pro.vytal.fit | Staff and backoffice |
| myVytal | my.vytal.fit | The athlete portal |
| API | api.vytal.fit/v1 | Integrations and the contract |
Start here
- Quickstart: create a key, make a call.
- Authentication: API keys in depth.
- Conventions: org scope, list shape, dates, idempotency.
- Errors: one error shape, predictable status codes.
- API Examples: copy/paste for bookings, records, results.
- REST Principles: how the surface is shaped.
A typical first integration
- Create an API key in Settings ā API Keys and store it as a secret.
- Read something real: your members, or today's classes.
- Write something: book a member into a class; full classes auto-waitlist.
- Handle errors on the shared
{ error, message }shape.
When you are ready for the machine-readable contract, point your tooling at the
OpenAPI spec.
What to expect
- A versioned
/v1base path with clean, resource-oriented routes. - API-key auth on every call (
Authorization: Bearer vk_live_ā¦). - Org-scoped data with strict tenant isolation.
- PT, EN, and ES across every product surface.
Updated about 2 months ago
Did this page help you?
