Step 7 The basics

Purpose (Product)

• Collect core capacity details that define the listing: guests, bedrooms, beds, and bathrooms.

• These values power search ranking, pricing guidance, cleaning and inventory planning, and are used to scaffold the property’s room structure for later steps (photos, amenities, etc.).

UX Flow (What the user sees)

• A single screen with four counters:

  • Guests (capacity)

  • Bedrooms

  • Beds

  • Bathrooms

• Each counter has +/− controls with sensible bounds. Validation requires all values >= 1.

• On Next, values are saved and the system auto-generates room entities (Bedrooms, Bathrooms) for downstream steps (e.g., photo tagging).

• On success, the flow advances to the next step.

![[Desktop 6.png]]

Validation rules and error states

• Client schema:

  • capacity ≥ 1

  • bedrooms ≥ 1

  • beds ≥ 1

  • bathrooms ≥ 1

• UI constraints:

  • Counters typically bounded to [1..50]

• Error states:

  • Client validation fails → inline error, no API calls

  • PATCH/POST fails → user remains on step; parent displays an error banner (or console log)

APIs Called

PATCH /api/properties/{propertyId}

• Purpose: Update property details (capacity, bedrooms, beds, bathrooms)

• Payload:

  • { propertyDetails: { capacity: number, bedrooms: number, beds: number, bathrooms: number } }

• Response: Updated property

• Errors: 400, 401/403, 404, 500

• Idempotency: Safe for identical values

POST /api/properties/{propertyId}/property-rooms

• Purpose: Create room entities (called multiple times)

• Payload:

  • { name: string, type: 'BEDROOM'|'BATHROOM', order: number }

• Response: Created room entity

• Errors: 400, 401/403, 404, 409 (if server guards duplicates), 500

• Idempotency: Not guaranteed; re-submission can create duplicate rooms if backend doesn’t dedupe

PATCH /api/users/{userId}

• Purpose: Increment user's onboarding step

• Payload:

  • { onboardingStep: number } (current + 1)

• Response: Updated user

• Errors: 400, 401/403, 404, 500

GET /api/properties

• Purpose: Refetch to update client cache

QA Checklist

1

Visual

• Four counters render with +/− controls and proper min/max behavior

2

Behavior

• With any value < 1 → inline validation error; blocked submission

• On valid submit → PATCH propertyDetails, POST rooms per counts, increment onboardingStep, refetch properties, proceed

3

Data

• propertyDetails.capacity/bedrooms/beds/bathrooms updated on the property

• Appropriate number of property-room entities created with correct names, types, and order

• users.onboardingStep increments exactly once

4

Negative

• Simulate API failure on PATCH or first POST: user remains on step; no step increment or navigation

• Re-submit the same values: no duplicate propertyDetails; assess whether rooms duplicate (backend responsibility)