All booking and tour creation endpoints now accept an optional service_key parameter as a more stable, human-readable alternative to service_id for selecting a hailing service.

Unlike UUIDs, service keys are immutable, descriptive identifiers (e.g., default, express) that stay stable across different tenants and between test and production environments — no need to look up the exact UUID for a specific service on each tenant. We recommend using service_key for new integrations where possible.

The service object in booking responses now includes a key field alongside the existing id, and you can discover all available service keys via the Services configuration endpoint.

Important: service_id and service_key cannot be combined in the same request. If both are provided, a validation error will be returned. When neither is given, the tenant’s default service is used — this behavior is unchanged.