Create timeslot
REQUEST BODY
Required attributes:
- title String / the title of the session happening in this timeslot
- start_time DateTime / the start date and time; see notes for more information on formatting
- end_time DateTime / the start date and time; see notes for more information on formatting
- external_id String / see notes for more information
- tags List / if not used, an empty list [] must be sent
Notes:
01: start_time and end_time must be specified in the following format:
- YYYY-MM-DDTHH:mm:ssZ
- eg: 2029-06-10T14:30:00+0200
- The timezone of the event must be specified accurately, as the API will pass data in UTC time. In the example above +0200 refers to Helsinki time.
- Make sure that the date and time are within the event dates specified in Brella (if your event dates aren't correctly set-up in Brella, first do so via the Admin Panel (Event > Details).
- You may need to do some formatting within your integration before passing this data to Brella
02: track is not technically required, but is highly recommended when passing timeslots via the API — especially if multiple sessions take place simultaneously. A single track cannot have overlapping sessions — the endpoint will return an error if this is the case.
- If the track attribute is empty / not passed, Brella will automatically assign the timeslot being created by the request to the default track.
- The tracks can be existing schedule tracks (created in the Admin Panel), or tracks that do not exist. If the value passed in the track attribute doesn't match an existing track's name, Brella will create a new track named with the value of the track attribute in the request and assign the timeslot there.
03: external_id is not technically required, but is highly recommended when passing timeslots via the API. This value is used to update timeslots, and to find specific timeslots via the API. Typically, it would contain a shared value between the 3rd party system the data is coming from and Brella (eg: you could pass the unique identifier generated by the 3rd party system to the external_id attribute in Brella.
04: uses_rsvp, uses_attendee_list uses_ticket_qr_code, attendance_registration_open and attendance_cap allow you to control whether a session can be reserved /RSVPd in Brella.
- uses_rsvp : (boolean/ true or false) Turns the feature on at the highest level. Also required in order to allow our RSVP endpoints to be used with this timeslot. This alone will NOT allow attendees to register for the timeslot in the app.
- uses_attendee_list: (boolean/ true or false) Show a list of all attendees within the app who have RSVPd for a particular session
- uses_ticket_qr_code: (boolean/ true or false) Show the attendee's code in the session page of the app
- attendance_registration_open: (boolean/ true or false) Allow attendees to actually register for the ression via the app. This can be turned off at any time, after which attendees can remove their RSVPs, but not register for new sessions.
- attendance_cap: (integer) Limit how many attendees can register for a particular session
05: attendee_group_ids: (array containing integers) If you have existing user groups in Brella, you can allow only specific user groups to see / access this session. Send the group_ids of the user groups that should be able to see this timeslot into this array.