@slotchain/sdk 1.2.3 → 1.3.0

package/dist/index.d.mts

@@ -257,6 +257,8 @@ interface FindOrCreateCustomerOptions {
     customer_type?: 'individual' | 'organization';
     is_guest?: boolean;
     metadata?: Record<string, unknown>;
+    /** IDP user ID (Auth0 sub, Clerk userId, etc.) — if provided, a customer_users row is upserted server-side */
+    idp_id?: string;
 }
 interface Flow {
     id: string;
@@ -598,9 +600,14 @@ declare class BookingClient {
     /**
      * Create a new booking (publishes booking.created event)
      * POST /api/v1/bookings
+     *
+     * Provide either `slot_id` (explicit) or `tenant_id` (auto-resolve).
+     * When only `tenant_id` is given the API resolves the first active slot for that tenant,
+     * creating a default slot if none exists — so callers never need to manage slot IDs.
      */
     create(data: {
-        slot_id: string;
+        slot_id?: string;
+        tenant_id?: string;
         customer_info: {
             name: string;
             email: string;
@@ -613,6 +620,40 @@ declare class BookingClient {
         };
         booking_data?: Record<string, unknown>;
     }): Promise<ApiResponse<Booking>>;
+    /**
+     * Create a booking for a specific service item (job posting, class, product, etc.)
+     * without requiring the caller to supply or know a slot ID.
+     *
+     * The API resolves the correct slot for the tenant automatically, creating a
+     * default slot if none exists. This is the preferred method for application flows
+     * where slots are an internal infrastructure concern, not a user-facing concept.
+     *
+     * POST /api/v1/bookings  (with tenant_id instead of slot_id)
+     *
+     * @example
+     * ```typescript
+     * const booking = await slotly.booking.createFromServiceItem({
+     *   tenantId: 'tenant-123',
+     *   serviceId: 'service-abc',
+     *   serviceItemId: 'item-xyz',
+     *   customerInfo: { name: 'Jane Smith', email: 'jane@example.com' },
+     *   extraData: { kind: 'job_application', booking_moment: 'submitted' },
+     * });
+     * ```
+     */
+    createFromServiceItem(data: {
+        tenantId: string;
+        serviceId: string;
+        serviceItemId: string;
+        customerInfo: {
+            name: string;
+            email: string;
+            phone?: string;
+            isGuestCheckout?: boolean;
+        };
+        /** Additional fields merged into booking_data alongside service/item IDs */
+        extraData?: Record<string, unknown>;
+    }): Promise<ApiResponse<Booking>>;
     /**
      * Update booking by ID
      * PUT /api/v1/bookings/:id

package/dist/index.d.ts

@@ -257,6 +257,8 @@ interface FindOrCreateCustomerOptions {
     customer_type?: 'individual' | 'organization';
     is_guest?: boolean;
     metadata?: Record<string, unknown>;
+    /** IDP user ID (Auth0 sub, Clerk userId, etc.) — if provided, a customer_users row is upserted server-side */
+    idp_id?: string;
 }
 interface Flow {
     id: string;
@@ -598,9 +600,14 @@ declare class BookingClient {
     /**
      * Create a new booking (publishes booking.created event)
      * POST /api/v1/bookings
+     *
+     * Provide either `slot_id` (explicit) or `tenant_id` (auto-resolve).
+     * When only `tenant_id` is given the API resolves the first active slot for that tenant,
+     * creating a default slot if none exists — so callers never need to manage slot IDs.
      */
     create(data: {
-        slot_id: string;
+        slot_id?: string;
+        tenant_id?: string;
         customer_info: {
             name: string;
             email: string;
@@ -613,6 +620,40 @@ declare class BookingClient {
         };
         booking_data?: Record<string, unknown>;
     }): Promise<ApiResponse<Booking>>;
+    /**
+     * Create a booking for a specific service item (job posting, class, product, etc.)
+     * without requiring the caller to supply or know a slot ID.
+     *
+     * The API resolves the correct slot for the tenant automatically, creating a
+     * default slot if none exists. This is the preferred method for application flows
+     * where slots are an internal infrastructure concern, not a user-facing concept.
+     *
+     * POST /api/v1/bookings  (with tenant_id instead of slot_id)
+     *
+     * @example
+     * ```typescript
+     * const booking = await slotly.booking.createFromServiceItem({
+     *   tenantId: 'tenant-123',
+     *   serviceId: 'service-abc',
+     *   serviceItemId: 'item-xyz',
+     *   customerInfo: { name: 'Jane Smith', email: 'jane@example.com' },
+     *   extraData: { kind: 'job_application', booking_moment: 'submitted' },
+     * });
+     * ```
+     */
+    createFromServiceItem(data: {
+        tenantId: string;
+        serviceId: string;
+        serviceItemId: string;
+        customerInfo: {
+            name: string;
+            email: string;
+            phone?: string;
+            isGuestCheckout?: boolean;
+        };
+        /** Additional fields merged into booking_data alongside service/item IDs */
+        extraData?: Record<string, unknown>;
+    }): Promise<ApiResponse<Booking>>;
     /**
      * Update booking by ID
      * PUT /api/v1/bookings/:id

package/dist/index.esm.js

@@ -265,6 +265,10 @@ var BookingClient = class {
   /**
    * Create a new booking (publishes booking.created event)
    * POST /api/v1/bookings
+   *
+   * Provide either `slot_id` (explicit) or `tenant_id` (auto-resolve).
+   * When only `tenant_id` is given the API resolves the first active slot for that tenant,
+   * creating a default slot if none exists — so callers never need to manage slot IDs.
    */
   async create(data) {
     const response = await this.client.post(
@@ -273,6 +277,38 @@ var BookingClient = class {
     );
     return response.data;
   }
+  /**
+   * Create a booking for a specific service item (job posting, class, product, etc.)
+   * without requiring the caller to supply or know a slot ID.
+   *
+   * The API resolves the correct slot for the tenant automatically, creating a
+   * default slot if none exists. This is the preferred method for application flows
+   * where slots are an internal infrastructure concern, not a user-facing concept.
+   *
+   * POST /api/v1/bookings  (with tenant_id instead of slot_id)
+   *
+   * @example
+   * ```typescript
+   * const booking = await slotly.booking.createFromServiceItem({
+   *   tenantId: 'tenant-123',
+   *   serviceId: 'service-abc',
+   *   serviceItemId: 'item-xyz',
+   *   customerInfo: { name: 'Jane Smith', email: 'jane@example.com' },
+   *   extraData: { kind: 'job_application', booking_moment: 'submitted' },
+   * });
+   * ```
+   */
+  async createFromServiceItem(data) {
+    return this.create({
+      tenant_id: data.tenantId,
+      customer_info: data.customerInfo,
+      booking_data: {
+        service_id: data.serviceId,
+        service_item_id: data.serviceItemId,
+        ...data.extraData
+      }
+    });
+  }
   /**
    * Update booking by ID
    * PUT /api/v1/bookings/:id