Ok, so I’m going to (partly) answer my own question here. So the Messages api does return an individual message’s content as a list of base64 strings called parts. Each part contains mimeType text and body data for whatever is in the message–rich text, attached images, files, etc
However, the API also seems to return a mimeType multipart/alternative. This is when messages have mixed text and embeded images in line. In this case, when multipart/alternative is used, the body b64 text is empty and the documentation seems to suggest that the recursive parts object is full of additional data for this mime type.
You can use the base64 plugin from Zeroqode to decode the base64 returned by this plugins, but if the plugin template doesn’t support additional nested layers for data on these more complex messages, then it doesn’t much matter.
By including a 2nd layer of parts array into gmail api response template for this plugin, would allow for some way to dig into multipart/alternative messages. Right now the body for multipart/alternative message is empty the missing data being under the parts array.
From the google documentation about parts
https://developers.google.com/gmail/api/reference/rest/v1/users.messages#Message
The child MIME message parts of this part. This only applies to container MIME message parts, for example multipart/* . For non- container MIME message part types, such as text/plain , this field is empty. For more information, see RFC 1521.
If anyone knows a solution to reading message text into bubble
