Cisco Unity Connection Messaging Interface (CUMI) API -- Using the CUMI API

From DocWiki

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
'''Other API pages:''' [[Cisco_Unity_Connection_APIs]]
{| border="1" class="wikitable"
! style="background-color: rgb(255, 215, 0);" | '''Back to:''' [[Cisco Unity Connection Messaging Interface (CUMI) API|CUMI API Overview ]]
{| align="right" border="1"
{| align="right" border="1"
|align="center"|'''CUMI Guide Contents'''
|align="center"|'''CUMI Guide Contents'''

Revision as of 06:56, 1 March 2012

Back to: CUMI API Overview
CUMI Guide Contents
CUMI API Overview
Using the CUMI API for Mailboxes & Folders
Using the CUMI API for Sending Messages
Using the CUMI API for Sending Notifications
Using the CUMI API for Broadcast Messages
HTTP Samples
Sending a Voice Message with One or More Attachments
Preventing Messages from Being Deleted (Investigative Hold)


About Mailboxes and Folders

The root of the Cisco Unity Connection Messaging Interface (CUMI) API is the Mailbox resource that is associated with each user. This contains some general information about the user's mailbox, and also contains a Folders resource that lists the folders for the mailbox. This list is currently fixed, although it is possible that folders may be added in the future.

Doing a GET on the Mailbox returns properties of the mailbox (for example, quotas) as well as a link to the Folders element for the mailbox:

GET /vmrest/mailbox
<xs:complexType name="Mailbox">
<xs:element name="DisplayName" type="xs:string" />
<xs:element name="CurrentSizeInBytes" type="xs:long" />
<xs:element name="IsPrimary" type="xs:boolean" />
<xs:element name="IsStoreMounted" type="xs:boolean" />
<xs:element name="IsStoreOverFlowed" type="xs:boolean" />
<xs:element name="IsMailboxMounted" type="xs:boolean" />
<xs:element name="IsWarningQuotaExceeded" type="xs:boolean" />
<xs:element name="IsReceiveQuotaExceeded" type="xs:boolean" />
<xs:element name="IsSendQuotaExceeded" type="xs:boolean" />
<xs:element name="WarningQuota" type="xs:long" />
<xs:element name="ReceiveQuota" type="xs:long" />
<xs:element name="SendQuota" type="xs:long" />
<xs:element name="IsDeletedFolderEnabled" type="xs:boolean" />
<xs:element name="FoldersURI" type="xs:anyURI" />

Doing a GET on the Folders returns the fixed list of folders:

GET /vmrest/mailbox/folders

A Folder consists of a small set of properties (DisplayName and MessageCount) and a collection of Messages.

Doing a GET on a Folder returns a small folder resource object and a reference to its list of Messages:


Doing a GET on <folder>/messages returns a message list:


HTTP requests for Messages differ by folder, so they are listed here separately for each folder:

Folder Request Description
inbox/messages GET Returns read and unread messages that are not drafts or deleted messages.
inbox/messages PUT Can be used to update the message subject only.
inbox/messages DELETE Depending on system settings, either removes message or moves it to the "deleted" folder.
inbox/messages POST?method=accept Causes a dispatch message to be accepted.
inbox/messages POST?method=reject Causes a dispatch message to be rejected.
deleted/messages GET Returns list of deleted messages (if the system is set to "soft" delete - otherwise the list will always be empty).
deleted/messages DELETE Removes messages from the deleted folder (does a "hard" delete).
deleted/messages POST?method=empty Empties the deleted folder (permanently removes all messages in the folder).
deleted/messages POST?method=undelete Undeletes the specified message.
sent/messages GET Returns a list of recently sent messages.
sent/messages DELETE Deletes a message from the sent list.

A dispatch message is a message that needs to go to one and only one member of a group. When the message is accepted by any one user, it is no longer available to other users. When the message is rejected by a user in the group, it is removed from the user's voicemail list.

Offset and Limit

Each of the folders will accept the parameters "pagenumber" and "rowsperpage" to specify which messages to retrieve:



Initially, server-side sorting will be limited to what can be done efficiently by the database, and will default to placing new messages first, followed by read messages, and sorted within each by ArrivalTime.

As recommended in the VTG REST guidelines, sorting will be controlled via "sortkey" and "sortorder" parameters, although initially only the following sort orders will be supported by the server:

Sort Description Sort Parameters
Newest first no parameters (default) or sortkey=arrivaltime&sortorder=descending
Oldest first sortkey=arrivaltime&sortorder=ascending
Urgent first sortkey=priority&sortorder=descending


Filtering can be done on the folders by read, priority, voice, fax and dispatch.



To get a list of unheard voice messages:

GET /vmrest/mailbox/folders/inbox/messages?read=false&type=voice

To get a list of unheard urgent messages:

GET /vmrest/mailbox/folders/inbox/messages?read=false&priority=urgent

To get a list of saved (deleted) messages:

GET /vmrest/mailbox/folders/deleted/messages

Back to: CUMI API Overview

Rating: 4.3/5 (3 votes cast)

Personal tools