The call object

Returned by every route under /v1/calls. A call answers the same five routes as a meeting and carries the same fields except bot_history; what else changes is which records the collection holds and how they usually look.

Every field is documented on the meeting object. What follows is only what differs.

What differs

object

call, never meeting. It is the field that says which resource you hold.

id

Prefixed call_. A mtg_ id does not resolve under /v1/calls, and the reverse is also a 404.

participants

Usually a single entry carrying phone. A VoIP record identifies the other party by number, not by email.

type

Usually audio, but not always. Calls in video exist; object is what tells the resource apart, never type.

enablement.meeting_type

Often null. The classifier was built for sales meetings and does not label calls.

Fields a call does not have

bot_history is not on this object: a VoIP capture has no recording bot, so the field never applies and the response omits it rather than sending an empty array. A schema that validates a call rejects the field.

enablement.meeting_type stays, and is often null. That null is legitimate — the sales-stage classifier does not label calls today, but it could. It is not the same case as the bot.

Note

This page is generated from the OpenAPI specification. Do not edit it by hand.