# Calendar activities If an activity is not an [open date activity](/api/catalog/activities/types/open-date), customers *must* select an available date from a calendar as part of the booking flow. Depending on the activity configuration, after selecting a valid date, customers might need to select an available time too. The type of calendar is defined by the `booking_type` property in the `/activities/{activityUuid}` endpoint. ## Date only When an activity's `booking_type` property is `CALENDAR-NO-TIMESLOTS`, customers must *not* select a time as part of the booking flow. This is a common scenario for attractions such as museums where a customer's admission is valid at any time for the selected date. An example of an activity where customers are required to select only a date has been set up in the sandbox environment: ```bash curl -X GET '{baseUrl}/activities/d38cea83-02f6-47b3-abd6-5abbf812e27a' \ -H 'X-Musement-Application: {applicationValue}' \ -H 'X-Musement-Version: 3.4.0' \ -H 'Authorization: Bearer {accessToken}' ``` Response: ```json { [...] "booking_type": "CALENDAR-NO-TIMESLOTS", [...] "daily": true, [...] "open": false, [...] } ``` Note that the property `daily` will always be `true` for "date-only" activities, highlighting that customers must not choose a time as part of the booking flow. Ignore this property for activities with a different `booking_type` value. Be aware that times for these activities will still appear in the `/activities/{activityUuid}/dates/{date}` endpoint: ```json [ { "groups": [ { [...] "type": "DAY-BASED", "slots": [ { "time": "09:00", "languages": [], "products": [...] } ] } ] } ] ``` The `type` property for each group in the endpoint will be `DAY-BASED`, an additional reminder that the time is not part of the booking flow. Times for such activities are not necessarily based on attraction operating hours and could be random. Partners are encouraged to avoid showing times to customers when dealing with activities that only require dates. ## Date and time When an activity's `booking_type` property is `CALENDAR-TIMESLOTS`, customers *must* select a time as part of the booking flow. This scenario is common for tours which have precise starting times. Customers should first choose a date and then select an available time for that date. An example activity which requires selecting both a date and time has been set up in the sandbox environment: ```bash curl -X GET '{baseUrl}/activities/5a002d99-781b-479b-9a9d-9efadfd34ec2' \ -H 'X-Musement-Application: {applicationValue}' \ -H 'X-Musement-Version: 3.4.0' \ -H 'Authorization: Bearer {accessToken}' ``` Response: ```json { [...] "booking_type": "CALENDAR-TIMESLOTS", [...] } ``` Depending on the activity configuration, the `/activities/{activityUuid}/dates/{date}` endpoint may show one or more timeslots. Partners are expected to show customers all available times for the date as part of the booking flow.