Schedule events and read replies with a hub key

This page covers scheduling a case's eventsEvent An appointment on a case, such as a meeting or a call, that people are invited to and can accept or decline. and reading the replies with a hub key. Paths are under https://prd-api-app.caseactive.com/v1/<hub id>/<case id>.

Calls

Creating an event

Each person's email shows the time in their own time zone. A repeating event's calendar file names the zone it repeats in, so their calendar keeps it at its time too.

curl -X POST https://prd-api-app.caseactive.com/v1/ca-7e6d5c4b3a2f10/cc-1a2b3c4d5e6f70/events \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Consultation with Alex Rivera", "duration": {"start_date": "2026-10-12T14:00:00-04:00", "end_date": "2026-10-12T15:00:00-04:00"}, "location": {"location_type": "video_conference", "address": "https://meet.example.com/demo-injury-law"}, "participants_ids": ["cu-4f1c2a9e8b7d60", "cu-9d8c7b6a5f4e30"], "notifications": {"names": ["days"], "values": [-1440]}, "published": 1}'

It answers 201 with the event_id.

What happens next

When an event is published:

• Each attendee is emailed an invitation with a calendar file, or texted if they have no confirmed email, at once, unless instant_notify is false. The invitation links to the video meeting, if there is one, and a repeating event's calendar file carries its repeat. It appears on their To DoTo Do The list on a case of things waiting for you, such as forms to fill in, documents to sign or events to confirm. and in their portal notifications.
• Reminders go out at each time in notifications still ahead, by email without the calendar file, or by text.
• Each attendee answers yes, no or maybe in the portal, or from their calendar app. It leaves their To Do once they answer or the event starts.
• At its start, a one-off event becomes past. A repeating event moves to its next date and takes fresh answers.
• Nothing is written to anyone's connected calendar: the calendar file is how it gets there.

An event whose start has already passed is saved as past: nobody is invited or reminded, and it's on nobody's To Do. Use this to copy past appointments in from your calendar.

A draft tells nobody. Publish it later with PUT /events/<event_id> and {"published": 1}: its attendees are invited at once. A published event can't go back to a draft.

Changing or cancelling

PUT /events/<event_id> takes the same fields, and changes only the ones you send. Send duration whole: leaving out rrule ends the repeat. Leaving out zoneinfo keeps the time zone the repeat already has.

• Changing the name, description, times, repeat or location of an upcoming published event emails every attendee "Event Updated" with a new calendar file. Moving the start clears every attendee's answer, so they're asked again and it's back on their To Do; other changes keep the answers. A change to anything else tells them nothing.
• People you add are invited; people you remove are sent a cancellation.
• Reminders move with the start time; nothing else is sent at once.

DELETE /events/<event_id> cancels it. Attendees of an upcoming published event are emailed a cancellation with a calendar file that removes it. A repeating event is cancelled whole.

PUT /events/<event_id>/past, with no body, closes out an event that has already happened, such as a call held a day early. A one-off event keeps its date, becomes past, leaves To Do and stops reminding. A repeating event moves to the date after the one it was on, with fresh answers, and its reminders move with it. Nobody is told, and it stays in attendees' calendars, so to call an event off, delete it instead. It answers 200 with the event_id.

Replies

GET /events/<event_id>/responses lists each attendee's reply, oldest first, all on one page. Each holds the attendee's user_id, response.rsvp (yes, no or maybe) and when they answered. A repeating event lists only the current date's.

When an attendee answers, the staff on the case are told, as they would be if they'd scheduled it themselves. A key can't answer for anyone.

Finding a free time

GET /events/availability finds times when the people you name are all free, from their connected calendars.

It answers items, each a free time with start_time and end_time in Unix seconds and the user_ids it suits. Times start every 15 minutes, within each person's bookable hours, and date is read in the time zone your hub was created in. Only people on the case with a calendar connected to your hub count; with none, the list is empty. See Set the hours people can book with you.

Listing events

GET /events needs filter:

Each event holds its event_id, name, description, start_date, end_date, duration, rrule, zoneinfo, location, participants_ids, permissions, published, responses and notifications. upcoming and past leave out events limited to roles that don't include Bots.

If a call is refused

For the error body and the rest of the codes, see Handle API errors and status codes.