A time can be available when the message is prepared and unavailable when the customer chooses it. The integration needs to handle that change without promising a booking it has not recorded.
Where should the offered times come from?
Retrieve available slots from the system that owns the service and booking rules. Preserve the location, time zone and slot reference in the interaction.
Apple’s time-picker structure carries a native choice; your application supplies its business meaning.
What happens after the selection?
Recheck availability so you do not book a slot that another customer has taken. Complete the booking system’s account checks to verify that the customer is eligible. Confirm the appointment details with the customer to avoid recording the wrong booking. Then create the booking.
Return the recorded appointment details when it succeeds. Offer current alternatives when it cannot accept the selected slot.
What if the booking response is lost?
Inspect the original booking operation before trying again. It may have succeeded even though the reply did not reach your integration.
Keep the request and booking references available to recovery so a timeout does not create duplicate appointments.
How do I verify the complete experience?
Test the displayed date and time on intended devices, then confirm the selected result in the booking system. Include a stale slot and an uncertain response.
Connect the selected time to the booking system, then return its confirmed appointment or available alternatives to the conversation.