Réservations›Confirmer une réservation au nom du client
Confirmer une réservation au nom du client
Déclenche l'action `confirm_booking` de l'acteur client depuis la surface ENTREPRISE (auditée comme business_on_behalf). Deux usages : (1) LIVE — le personnel confirme un créneau pour un client ayant réservé par téléphone ; (2) SANDBOX — la surface à jeton magique du client est réservée au live (le lien d'une intervention sandbox ne peut jamais atteindre un vrai client), c'est donc la SEULE façon de faire progresser une intervention de test sandbox au-delà de la réservation (book → quote → confirm → assign → complete). Le corps porte le scheduled_at choisi par le client (date-heure locale de l'entreprise, naïve).
TABLE DE DÉCISION — chaque 409 renvoyé par cet endpoint, et l'ÉTAPE SUIVANTE correcte (branchez sur error_code, jamais sur le statut HTTP) :
• JOB_REQUEST_STAGE_CONFLICT — l'intervention a changé depuis votre lecture (NOTE : chaque tentative de confirmation ÉCHOUÉE incrémente aussi status_version, à dessein). Suite : re-GET l'intervention, réessayez avec le status_version à jour.
• JOB_REQUEST_ACTION_NOT_PENDING — l'intervention n'est plus à l'étape de confirmation (généralement : déjà confirmée). Suite : re-GET et affichez le statut actuel ; ne réessayez pas.
• JOB_REQUEST_NO_TECHNICIAN_AVAILABLE — l'HORAIRE est irréalisable pour tout le monde (hors heures de travail / hors fenêtre client, ou personne ne qualifie). Suite : choisissez une autre heure via booking-windows / time-segments. PAS un cas d'urgence — le déplacement ne peut pas créer de la capacité.
• JOB_REQUEST_TECH_INFEASIBLE — le technicien IMPOSÉ ne peut jamais prendre l'intervention à ce moment ; `data.reason` explique pourquoi : cannot_arrive_in_time (trajet/début de service — `data.earliest_feasible_at` (RFC3339 UTC) est la première heure du jour même où il PEUT être sur site → proposez-la) | missing_required_skills | not_available_today | not_lead_tier. Suite : gardez le technicien et reprogrammez à earliest_feasible_at ou après, OU gardez l'heure et retirez technician_id (sélection auto) / choisissez un autre technicien depuis time-segments. PAS un cas d'urgence.
• JOB_REQUEST_P0_REQUIRES_DISPLACEMENT — le SEUL code qui aiguille vers le flux d'URGENCE : l'intervention est P0, le technicien qualifie, mais la voie est réellement occupée. Suite : POST emergency/candidates → preview → commit (la validation confirme automatiquement). Réserve : si les interventions occupantes sont elles-mêmes P0, l'aperçu rejettera avec EMERGENCY_RESCHEDULE_SLOT_OCCUPIED (un P0 ne déplace jamais un P0) — choisissez alors un autre technicien/une autre heure.
Arguments
idstringpathrequis
ID de la demande d'intervention
Idempotency-Keystringheaderoptionnel
Unique key making retries safe: a repeat send with the same key replays the original response (header Idempotent-Replayed: true) instead of re-running the operation. Reusing a key with a different body returns 422 IDEMPOTENCY_KEY_REUSE.
arrival_window_minutesintegerbodyoptionnel
ArrivalWindowMinutes = largeur (en minutes) de la fenêtre d'arrivée que le client a sélectionnée dans le sélecteur de créneaux (c'est time_slot_step_minutes, 30 par défaut). Persistée pour que le détail post-confirmation réaffiche la bonne fenêtre. Facultatif ; les bornes ([5, 240], alignées sur le pas du sélecteur de créneaux) sont validées dans le cas d'usage — autorité unique, un seul code d'erreur (JOB_REQUEST_INVALID_INPUT).
scheduled_atstringbodyoptionnel
Chosen start time — business-local naive datetime, no offset (the business_time.datetime value from the time-segments picker). The server converts to UTC using the job's business timezone.
status_versionintegerbodyoptionnel
Optimistic-lock fence: the status_version from your last read. Omitted/0 = fence on the row's current version (no race protection).
technician_idstringbodyoptionnel
TechnicianID (confirmation ENTREPRISE uniquement — ignoré sur la surface client) :
force l'affectation de l'intervention à ce technicien au lieu de la sélection auto classée.
Le classement est contourné ; la réalisabilité (heures/congés/géo/compétences), la
règle TierLead et la protection contre la double réservation s'appliquent toujours — un technicien
imposé irréalisable fait rejeter la confirmation (un P0 reçoit l'indice de déplacement).