Reassign booking

POST /api/v1/bookings/{bookingId}/reassign

Hand a call over to another closer of the team, and move it onto one of their free slots when they are busy at the current time, using the current permissions of the key holder. The school comes from the verified key. MCP equivalent: reassign_booking.

Without startsAt (or with the call's current start): only the closer changes. The closer must be free at the call's current time.
With another startsAt: the closer and the time change in one atomic command. The instant must be one returned by reassignment slots for this closer: in the future, within that closer's booking horizon, and free of calls, daily capacity and connected calendar events when the command is applied.

Authorization

Organization role

Role in the organization	This endpoint
OWNER	Allowed
ADMIN	Allowed
MEMBER	Head of Sales only — otherwise 403

Business authorization

Only an owner, an administrator or a Head of Sales in this school can perform this operation; setter and closer roles do not grant it. A Head of Sales member creates no API key: they reach this operation through an MCP OAuth connection. Reassigning changes the closer of this call only; the contact owner is unchanged.

Requirement	Rule
Business role	Head of Sales, for a member
Resource scope	Current school and the permitted resource scope
Participation	None
Resource state	Active future booking for a new mutation

Path parameters

Parameter	Type	Required	Description
`bookingId`	UUID	yes	Resource in the permitted school and scope.

Request headers

Header	Required	Description
`x-api-key`	yes	Key for this school.
`Idempotency-Key`	yes	Stable key for exactly one intention.
`X-Correlation-Id`	no	UUID for tracing this call.

Request body

Field	Type	Required	Nullable	Description
closerUserId	UUID	yes	no	A closer returned by the reassignment candidates endpoint.
startsAt	ISO 8601 string	no	no	Exact instant returned by the reassignment slots endpoint for this closer; include an offset. Omit it to keep the current time.
locale	string	no	no	Language of the prospect email: `fr`, `en` or `es`. Defaults to `fr`.

Example

bash

curl -X POST "$COHORTE_API_BASE_URL/api/v1/bookings/00000000-0000-4000-8000-000000000001/reassign" \
  -H "x-api-key: $COHORTE_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: scheduling-intention-001" \
  --data '{"closerUserId": "00000000-0000-4000-8000-000000000001", "startsAt": "2030-01-10T09:00:00Z"}'

Response

200 — successful read, mutation or retry.
400 — invalid request.
401 — invalid key, bearer or school membership.
403 — insufficient permission.
404 — booking absent or outside the permitted scope, or closer outside the active sales team.
409 — the closer is no longer free at the call's time, the chosen slot is no longer free for this closer, a changed intention for this key, or an unverifiable historical key. Reread candidates or slots before a new command.
500 — unexpected failure; retry only the identical intention.

Response fields

Field	Type	Nullable	Description
`success`	boolean	no	True on success.
`data`	object	no	Scoped records; no private management token.
`data.id`	UUID	no	Public identifier, when this endpoint returns a single resource.

Example response

json

{
  "success": true,
  "data": {
    "id": "00000000-0000-4000-8000-000000000001",
    "status": "rescheduled",
    "startsAt": "2030-01-10T09:00:00.000Z",
    "endsAt": "2030-01-10T09:45:00.000Z",
    "personId": "00000000-0000-4000-8000-000000000001",
    "prospectName": "Alex",
    "prospectEmail": null,
    "prospectPhone":

Notes

Reuse the same key only for the same normalized payload and resource. An identical retry rechecks current permissions, returns the resource and creates no new audit event or notification. A changed payload or an older unverifiable key returns 409; inspect the original outcome before deciding on any new command.

History is retained. A genuinely new mutation notifies the affected participants once through the existing notification flow. Staff never receive or reuse the prospect management token. Slot availability is checked again when applying the command.

What is sent after a new reassignment:

Recipient	Closer only	Closer and time
Prospect	No email — the time does not change; their manage page and reminders show the new link	Email with the new time, without the closer's name; no new confirmation request — a presence already confirmed stays confirmed
Former closer	Notification that the call is released	Notification that the call is released, at the time they held
New closer	Notification of the assigned call	Notification of the assigned call
Meeting link	The call's link becomes the new closer's default meeting link, or is cleared if they have none — never the former closer's	Same; the prospect email carries the new link
Calendars	Event moved from the former to the new closer's connected calendar	Same, at the new time

Reassigning never changes the contact owner, nor the rotation of a booking link.