# Clients & identity

Associate a person with the studio independently of a booking, or let supported admission create the association. Creating a client is not customer authentication or account activation.

## Inputs and prerequisites

[Create a client](/api/docs#/Studio%20clients/v2CreateClient) with at least `email`; names, phone and a studio-scoped `source`/`external_id` are optional. The default `account_type=external` links the normalized email to this studio.

Use current client creation authority and authorize the visitor in your backend. A matching global person retains their profile, credentials and login state; the response does not reveal their other studios.

## Choose when to associate

Ordinary booking/purchase commands can accept email directly, so a separate create call is optional where admission supports association. Quote reads instead accept an owned `client_id` when personalization is needed; they do not accept email or create a client.

A Tour requiring phone needs an explicit owned-client create/update before admission, because the Tour body does not accept arbitrary shared profile fields. Use [client update](/api/docs#/Studio%20clients/v2UpdateClient) with current authority rather than silently adding unsupported booking fields.

## Account activation is explicit

New external people cannot use Podyx sign-in while external. Client association and booking creation do not automatically send an activation invitation.

An authorized studio can request a standard account with the additional activation permission, or use [activation requests](/api/docs#/Studio%20clients/v2RequestClientActivation) with `clients:request_activation`. `send_invitation=false` retains a pending explicit request without email; it does not grant login.

Only the dedicated email-owner proof activates the same person and retains studio links and purchases. The customer follows the native activation confirmation. The proof is not a studio API-key login credential. A queued invitation does not establish delivery.

## Results and recovery

Retain the real returned client ID for current profile, rights and booking association. A write needs a persisted UUID header. If its response is lost, [retry the same command](/api/docs/guides/v2/recovery); do not create a second person to discover what happened. Read current client state with still-authorized credentials.

For a CRM purchase record, use [purchased bundle details](/api/docs/guides/v2/catalog#purchased-bundle-records-for-a-crm) by `member_bundle_id`. Current bundle rights only describe booking eligibility and do not enumerate exhausted purchases.

## Example

Explicitly request an invitation after the studio has chosen this action:

```sh
curl "https://app.podyx.com/api/v2/clients/$CLIENT_ID/activation-requests" \
  -H "Authorization: Bearer $PODYX_API_KEY" \
  -H "Idempotency-Key: $ACTIVATION_REQUEST_UUID" \
  -H 'Content-Type: application/json' \
  --data '{"send_invitation":true}'
```

Persist `ACTIVATION_REQUEST_UUID` before sending. Retrying an uncertain delivery uses the same UUID and body. Creating a client alone does not request this invitation.