Reschedule Schedule

Atomically move every active booking on an experience departure to a new datetime. Each affected customer is automatically notified by SMS and email with the new time plus a magic-link fallback so they can pick a different slot if the new time does not work for them.

Cancelled bookings are not touched. If any booking cannot move (for example, the target time already has bookings that would push it over capacity), the entire reschedule is rolled back — there is no half-completed state.

This is the supplier-side bulk-move flow. To let a single customer reschedule their own booking, use a magic-link reschedule URL (see customer self-service).

Endpoint

POST /v1/experiences/{id}/schedules/{scheduleId}/reschedule

Authentication

Requires an API key with the experiences:write scope.

Path Parameters

Parameter	Type	Description
id	integer	Experience ID
scheduleId	integer	Source schedule (departure) ID

Request Body

Field	Type	Required	Description
target_datetime	string	Yes	New start datetime in the supplier's timezone, format YYYY-MM-DD HH:MM.
reason	string	No	Short reason surfaced to customers in the SMS broadcast (max 255 chars), e.g. "low water level", "high winds".

Example Request

curl -X POST "https://app.equipdash.com/api/v1/experiences/12/schedules/487/reschedule" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_datetime": "2026-05-26 06:30",
    "reason": "low water level"
  }'

Response

Success (200 OK)

{
  "data": {
    "target_schedule_id": 512,
    "target_datetime": "2026-05-26T13:30:00.000000Z",
    "moved_booking_ids": [2389, 2391, 2402],
    "notifications": {
      "sent": 3,
      "failed": 0,
      "errors": []
    },
    "guide_warnings": []
  },
  "meta": {
    "request_id": "req_abc123",
    "timestamp": "2026-05-24T18:13:00+00:00"
  }
}

The target_schedule_id is the schedule the bookings were moved to. If a schedule already existed for this experience at the exact target datetime, it is reused; otherwise a new one is created with the capacity, duration and assigned guides of the source schedule.

Each entry in notifications.errors is a per-booking failure message — the move still committed, but the customer-facing email or SMS for that booking did not go out (the operator may want to follow up manually).

guide_warnings lists guides whose existing roster overlaps the new departure time. Conflicts are surfaced, never blocked.

Errors

Status	Code	Description
400	validation_error	Invalid request body (e.g. malformed target_datetime)
401	authentication_required	No API key provided
403	insufficient_scope	API key lacks experiences:write scope
404	not_found	Experience or schedule not found
422	conflict	The bulk reschedule could not complete (e.g. target slot lacks capacity, no-op move, slot belongs to another supplier). No bookings were moved.

Notes

• The move runs in a single database transaction. If any booking cannot move, every booking stays on the source departure — there is no partial-move state.
• The source departure is left in place (empty) so it remains in your history and audit trail. You can delete it afterwards if you wish.
• Each affected customer receives an SMS via your shop's SMS settings AND an email via the standard rescheduled-booking template. Both contain the new time and a magic-link reschedule URL.
• Guides assigned to the source departure are copied to the target departure. Guides with overlapping commitments at the new time are surfaced in guide_warnings but the reschedule still completes.