Guide
Meetings
One meeting, end to end: scheduled, filled with people, joined, ended, and read afterwards. Every step is a route you can call, and they go in this order.
Schedule one
One call makes the meeting and invites people to it. You get back the meeting with its join code, and an invites list saying how each address was reached.
POST/meetings
curl -X POST "$MORSE/meetings" \
-H "Authorization: Bearer $MORSE_TOKEN" \
-H "Content-Type: application/json" \
-H "X-Timezone: Asia/Kolkata" \
-d '{
"title": "Pricing review",
"scheduled_at": "2026-10-02T10:30:00+05:30",
"duration_minutes": 30,
"booked_timezone": "Asia/Kolkata",
"emails": ["arjun@neuralarc.ai"]
}'{
"id": "5e6f2b31-5c4a-4d0e-9a77-1b2c3d4e5f60",
"code": "4KJ9P2",
"title": "Pricing review",
"scheduled_at": "2026-10-02T10:30:00+05:30",
"duration_minutes": 30,
"calendar_sync_status": "synced",
"invites": [
{ "email": "arjun@neuralarc.ai", "delivery": "calendar" }
]
}delivery is calendar when the person is on your Google Calendar and got the event, email when they were sent an invitation instead, and none when neither worked. The meeting is created either way, and a failed send never costs you the meeting.
emails, inviting, rescheduling and sharing notes all send mail. Without the header the times in those emails are the server’s, not yours.Leave scheduled_at out and the meeting is for now. Include it, and booked_timezone is the zone the times should read in for everyone else.
Or describe it in words
If you are building something a person talks to, hand the sentence over instead of parsing it. /meetings/interpret reads a line of English and returns the parts: the date, time, length, names, addresses, and whether the assistant and recording were asked for. It does not create anything; you decide what to do with the answer.
POST/meetings/interpret
curl -X POST "$MORSE/meetings/interpret" \
-H "Authorization: Bearer $MORSE_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "text": "pricing review with Arjun Thursday 3pm UK time" }'Invite people
Up to twenty-five addresses a call and, unlike most of this page, anyone in the room may invite, not only the host. The reply is one entry per address, with the same delivery values as above.
POST/meetings/{meeting_id}/invites
curl -X POST "$MORSE/meetings/$ID/invites" \
-H "Authorization: Bearer $MORSE_TOKEN" \
-H "Content-Type: application/json" \
-H "X-Timezone: Asia/Kolkata" \
-d '{ "emails": ["priya@neuralarc.ai", "sam@example.com"] }'GET /invites lists who has been asked. To withdraw one, DELETE /invites/{email}, but only for someone who has not arrived yet. If your colleagues are on Google Calendar, GET /invites/responses gives you their answers to the event.
Join it
Joining returns a LiveKit token and the URL to connect to. Check status before you use it: a locked meeting answers waiting instead, meaning somebody has to let you in.
POST/meetings/{meeting_id}/join
curl -X POST "$MORSE/meetings/$ID/join" \
-H "Authorization: Bearer $MORSE_TOKEN"GET /occupancy tells you who is already in the room, which is what a pre-join screen is for: whether you are walking into an empty room or a conversation.
While it runs
The transcript streams as it is written, as server-sent events. Keep the connection open and read it as it arrives.
GET/meetings/{meeting_id}/transcript-events
curl -N "$MORSE/meetings/$ID/transcript-events" \
-H "Authorization: Bearer $MORSE_TOKEN"EventSource cannot send a header. From a web page use the app’s own session; from a script or an agent, the token works.End it
Ending stops the meeting for everyone and starts the notes being written. That takes a moment, so rather than polling, GET /summary-events nudges you when generation has finished and you refetch.
POST/meetings/{meeting_id}/end
curl -X POST "$MORSE/meetings/$ID/end" \
-H "Authorization: Bearer $MORSE_TOKEN"What it leaves behind
Three things, each on its own route.
# What was said
curl "$MORSE/meetings/$ID/transcript" -H "Authorization: Bearer $MORSE_TOKEN"
# The notes written from it
curl "$MORSE/meetings/$ID/summary" -H "Authorization: Bearer $MORSE_TOKEN"
# The recording, as links to each part
curl "$MORSE/meetings/$ID/recording" -H "Authorization: Bearer $MORSE_TOKEN"The notes are the host’s to review: PATCH /summary saves their version without ever overwriting the generated one, and POST /summary/send sends the reviewed artefact to chosen recipients. GET /summary/sensitive shows the host what would be hidden before they decide. The recording answers withheld to someone who may read the notes but not watch it back.
When plans change
Four different things, often confused. They differ in when you may call them and in who is affected.
| Route | When | Who | What it does |
|---|---|---|---|
POST /cancel | Before it starts | Host | It was never going to happen. Everyone invited is told. |
POST /end | While it is running | Host | Stops it for everyone and starts the notes being written. |
DELETE /meetings/{id} | Once it is over | Host | Hides it from everyone’s list. Reversible with /restore. |
POST /hide | Once it is over | Anyone who was in it | Removes it from your own list only. Nobody else is affected. |
PATCH /meetings/{id} covers renaming, rescheduling and re-lengthing. Host only. A reschedule emails everyone invited, so send X-Timezone with it.
Who may do what
The rule is narrower than it looks
- The host alone can rename, reschedule, cancel, end, delete and restore a meeting, and can regenerate or send its notes.
- Anyone in the room can invite more people. This is deliberate, and it is the exception worth remembering.
- Anyone who was in it can hide it from their own list, and read the notes if the host shared them.
A token acts as whoever made it, so all of the above is decided by who that person is . See Authentication. Every route on this page is listed with its full schema under Reference → Meetings.