Create timeslot

request body { "timeslots" \[{ "title" "{{session title}}", "start time" "{{yyyy mm ddthh\ mm\ ssz}}", "end time" "{{yyyy mm ddthh\ mm\ ssz}}", "content" "{{you can write \<p>html\</p> or just have a string anything here will be converted to draftjs consumable object}}", "track" "{{trackname}}", "location" "{{main hall and venue}}", "tags" \["tag 01", "tag 02", "tag 03", "tag 04", "tag 05"], "external id" "d00byd11 01" }] } 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