Business Management (1.0.0)

Start here: get your credentials

Business Management requests use a Partner Token and, when business data is involved, a User Token:

1. Open the Altegio Marketplace and click Developer account. Complete the developer registration. Your Partner Token then appears automatically under Account settings → Account details.

2. Choose how you will obtain the User Token:

   • Application system user: create an application in Developer Account. Under API Access, enter the system user's User ID, save it, copy the generated User Token, and configure the application's credentials, access rights, and connection settings. Then install and activate the application on a test Location. The token can access that Location only after the installation is active.
   • Your own Business User: call the user authorization endpoint with your Altegio login and password. Use data.user_token from the response. No application installation is needed, but that Business User must already have access to the Location.

3. Send both values in the same header:

   Authorization: Bearer <partner_token>, User <user_token>

An application's system user and your own Business User can have different Locations and permissions. A request that works with one token may therefore return 403 with the other. See How to Get API Keys for the complete beginner walkthrough.

Full-featured B2B API for business operations.

Base URL: https://api.alteg.io/api

⚠️ Version Status

V1 will be gradually deprecated. We recommend using V2 API for new integrations. V1 endpoints are maintained for backward compatibility, but new features will be released in V2 only.

V1 and V2 parameter aliases

V1 accepts canonical terminology for top-level query-string and request-body parameters while continuing to support legacy V1 names. Canonical names are copied to the legacy names read by V1 handlers; legacy names are not copied in the reverse direction. This makes it possible to share request-building code between API versions. Common alias families include:

• location_id, company_id, and salon_id
• chain_id, company_group_id, and salon_group_id
• team_member_id, staff_id, and master_id
• eventId and activityId (camelCase only)
• appointment_id and record_id
• product_id and good_id

Singular, plural, and camelCase variants are supported where explicitly documented. Send only one name from each alias family. If multiple aliases are supplied, explicitly supplied values are preserved and are not overwritten.

Alias expansion is not recursive: nested request fields must use the literal names shown by each endpoint. In particular, activity_id remains the V1 request field where it is documented. Responses are not transformed and retain their literal legacy wire fields and resource type values; response schemas and examples show those exact names.

Canonical URLs and permanent compatibility aliases

New integrations should use the canonical URL families below. Existing legacy URLs remain permanent compatibility aliases. Both reach the same V1 handlers with the same request method, authentication, permissions, status codes, and response bodies; the server routes them internally and does not redirect.

Only registered legacy method/path combinations are aliased; other URL shapes are not inferred. In particular, V1 has no event-list GET: a GET to /locations/{location_id}/events returns 405. URL aliases do not change response fields or webhook payload resource names.

Some older handlers have overlapping legacy shapes but different response contracts. Those endpoints remain documented on their literal legacy URL when the canonical URL resolves to the public compatibility handler instead.

Deprecation headers

Operations with a scheduled sunset return RFC 9745 and RFC 8594 headers on their responses:

They currently apply to Tags (/labels/...), Event create, read, update and delete (/locations/{location_id}/events[/{event_id}]), Position quick-create, and the Team Member Positions list. Each of these operations is marked deprecated in this reference.