Pular para o conteúdo principal

Clients API

Auto-generated from the OpenAPI spec. Run node docs-site/scripts/fetch-openapi.js to regenerate.

GET /api/v1/clients/me​

Get Own Profile

Responses

  • 200 — Successful Response

PUT /api/v1/clients/me​

Update Own Profile

Request body

FieldRequiredTypeDescription
full_nameNostring
phoneNostring
date_of_birthNostring
notesNostring
billing_nameNostring
billing_addressNostring
tax_idNostring
is_activeNoboolean

Responses

  • 200 — Successful Response
  • 422 — Validation Error

PUT /api/v1/clients/me/push-token​

Update Push Token

Responses

  • 200 — Successful Response
  • 422 — Validation Error

GET /api/v1/clients​

List Clients

Parameters

NameInRequiredTypeDescription
searchqueryNo
active_onlyqueryNoboolean
pagequeryNointeger
page_sizequeryNointeger

Responses

  • 200 — Successful Response
  • 422 — Validation Error

POST /api/v1/clients​

Create Client

Create a client from the backoffice (no password yet). Sends invitation email.

Request body

FieldRequiredTypeDescription
full_nameYesstring
emailYesstring
phoneNostring

Responses

  • 201 — Successful Response
  • 422 — Validation Error

GET /api/v1/clients/{client_id}​

Get Client

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger

Responses

  • 200 — Successful Response
  • 422 — Validation Error

PUT /api/v1/clients/{client_id}​

Update Client

Update a client's profile.

Also doubles as the genuine, reversible deactivate/reactivate path: passing is_active: false/true flips the flag directly, leaving full_name/email/phone/date_of_birth/notes untouched — same generic-PUT- reactivation convention as locations/class_templates/membership_types/ products/promo_codes/waivers/staff-pay-components/gift-cards in this codebase. This is deliberately distinct from anonymize_client (DELETE /clients/{id} below), which is an irreversible GDPR action that wipes PII and always sets is_active=False as a side effect — that endpoint is unchanged by this addition and remains independently reachable.

Downstream effect: Client.is_active is already enforced at the authentication boundary (app/auth.py::get_current_client and the login handlers in app/routers/auth.py both reject an inactive client with "not found or inactive" / AUTH_ACCOUNT_INACTIVE). So deactivating a client here immediately blocks their next login and invalidates any already-issued token's client-facing endpoints on next use; reactivating restores both. No new authorization logic was added — this only feeds into that existing check. Booking creation itself is not separately gated on Client.is_active (a manager booking on a client's behalf via POST /bookings does not check it), but that's an existing gap unrelated to this endpoint, not something this task should build out.

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger

Request body

FieldRequiredTypeDescription
full_nameNostring
phoneNostring
date_of_birthNostring
notesNostring
billing_nameNostring
billing_addressNostring
tax_idNostring
is_activeNoboolean

Responses

  • 200 — Successful Response
  • 422 — Validation Error

DELETE /api/v1/clients/{client_id}​

Anonymize Client

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger

Responses

  • 200 — Successful Response
  • 422 — Validation Error

POST /api/v1/clients/{client_id}/photo​

Upload Client Photo

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger

Responses

  • 200 — Successful Response
  • 422 — Validation Error

DELETE /api/v1/clients/{client_id}/photo​

Remove Client Photo

Clear a client's profile photo without uploading a replacement.

Idempotent: calling this when no photo is set is a no-op success, not a 404 — the end state (no photo) is what the caller asked for either way.

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger

Responses

  • 200 — Successful Response
  • 422 — Validation Error

GET /api/v1/clients/{client_id}/bookings​

Get Client Bookings

List a client's bookings for the desktop client-detail screen.

Paginated (same page / page_size / \{items,total,page,page_size\} convention as GET /clients). Each row carries the booking fields (id, scheduled_class_id, status, created_at) plus two display fields resolved via an outerjoin: class_name (the scheduled class's template name) and class_starts_at (its start datetime). Both are null when the scheduled class or its template row has since been deleted.

Ordering is newest class first: class_starts_at DESC with NULLs last (bookings whose scheduled class is gone sort to the end), then id DESC as a stable tiebreaker. total is the unpaginated booking count for the client; an out-of-range page yields an empty items with the real total.

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger
pagequeryNointeger
page_sizequeryNointeger

Responses

  • 200 — Successful Response
  • 422 — Validation Error

GET /api/v1/clients/{client_id}/memberships​

Get Client Memberships

List a client's memberships for the desktop client-detail screen.

Paginated (same page / page_size / \{items,total,page,page_size\} convention as GET /clients). Each row carries the membership fields (id, membership_type_id, status, starts_at, expires_at, credits_remaining) plus three display fields: membership_type_name and credits_total (the membership type's included credit count — null for unlimited / time-based types, or a deleted type row) are resolved via an outerjoin; credits_used is the membership's own stored booking-time usage ledger (Membership.credits_used, default 0, never null). The desktop gauge uses credits_used + credits_remaining as its denominator, so credits_total is informational only.

Ordering is newest first: starts_at DESC, then id DESC as a stable tiebreaker. total is the unpaginated membership count for the client; an out-of-range page yields an empty items with the real total.

Parameters

NameInRequiredTypeDescription
client_idpathYesinteger
pagequeryNointeger
page_sizequeryNointeger

Responses

  • 200 — Successful Response
  • 422 — Validation Error