Open Morse

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"]
  }'
201 Created
{
  "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.

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"

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.

curl
# 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.

RouteWhenWhoWhat it does
POST /cancelBefore it startsHostIt was never going to happen. Everyone invited is told.
POST /endWhile it is runningHostStops it for everyone and starts the notes being written.
DELETE /meetings/{id}Once it is overHostHides it from everyone’s list. Reversible with /restore.
POST /hideOnce it is overAnyone who was in itRemoves 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.