Asynchronous Cancellations
Depending on cancellation conditions or if a booking is flagged as potentially fraudulent on the SNCF side, a cancellation request might not be confirmed immediately. Instead, its status may be marked as "pending". To support this scenario, an asynchronous cancellation process must be implemented and managed on the retailer side to check for the final status of the cancellation.
Creating a Cancellation
The process begins similarly to a standard cancellation. After confirming the cancellation policies using the /cancellations/conditions endpoint, you create a cancellation using /cancellations/create.
However, for this asynchronous flow, the response will include a state of "pending" and a confirmation_expected_at timestamp. This timestamp indicates the earliest time you should check for a final update from the carrier.
Sample Response from /cancellations/create (Pending State)
Checking the Cancellation Status
To get the final status of a pending cancellation, you must schedule a follow-up call.
- Schedule the Check: Use the
confirmation_expected_attimestamp from the previous response to schedule a call to check the booking's status. - Poll the Booking Endpoint: Make a request to the /bookings/{booking_id} endpoint, using the ID of the original booking.
- Check the Final State: The updated status is available in the cancellation-related attributes within the booking response. The possible final values for the state field are:
confirmed,pending,rejected, andfailed. - Check for Rejection Reason: If the cancellation status is
rejected, the error message will appear in therejected_reasonfield.
By implementing this polling mechanism, you can reliably manage SNCF cancellations that require an asynchronous confirmation process.
What made this section unhelpful for you?
On this page
- Asynchronous Cancellations