for functions that are intended to be only ran by the currently active user we do not expose the userid typically i.e. we automatically add it via UserController.GetCurrentUserInfo().UserID -however these are normally just for audit columns (i.e. createdbyuserid, updatedbyuserid) though in the case of retrieving an inbox its assumed that only the user will read their inbox (i.e. that admin/host accounts should not be able to use the messaging centre to read users inboxes)

In general if you want to see how things work, you can examine the requests occurring when you do something via a http proxy such as fiddler (or the f12 tools in most browsers). Messaging was designed as a single-page-application with a service framework layer and that's the intended and recommended way to work with it.

You can of course take a look within the code and extract the relevant pieces but it's important to note that there are 2 locations to view the source:

Modules\CoreMessaging\Services\MessagingServiceController.cs

DotNetNuke.Web\InternalServices\MessagingServiceController.cs

As you can see the 2nd class is in an "internal" space i.e. we don't intend for users to use the methods in it directly (i.e. we do not regard it as part of the public API unlike the first class). That said I don't know why this was done for these methods, they seem link they should be public to me (I will look into it)

I would personally recommend you use the service framework calls e.g. http://cathaldnn.com/DesktopModules/I...
but if you cant for some reason then the relevant code is in the Create method of the 2nd class (as you can see by the url above) - you'll be looking to use something such as MessagingController.Instance.SendMessage(message, roles, users, fileIdsList) (note: there is no sender userid as we assume that the person using compose message is the sender - in the same way you do not have to specify a "from" address when writing an email)