Get a message

Message id (msg_...).

The address of your own line on this channel (the sending/receiving number or alias, e.g. +15559876543). Same value regardless of direction; sender/recipient tell you which side of the conversation it is on.

Transport state or resolved wire service; never null. pending = accepted and dispatched, wire service not resolved yet; imessage / rcs / sms = the device-confirmed transport (iMessage blue bubble, RCS, or SMS/MMS green bubble); whatsapp = sent over P2P WhatsApp; whatsapp_business = sent over the WhatsApp Business Platform (WABA); amb = sent over Apple Messages for Business; unknown = accepted but the transport could not be resolved before the tracking window closed (see error).

Who the message is FROM, direction-aware. On inbound this is the other party (the contact who messaged you, or in a group the participant who wrote it); on outbound this is your own line (channel_address). This is the SAME field delivered on the message webhooks, so a message reads identically via REST or webhook.

Who the message is TO, direction-aware. On inbound this is your own line (channel_address); on outbound this is the other party. The mirror of sender. Matches the message webhook shape.

Content type, e.g. text, media, poll.

The plain text of the message — what the recipient actually sees. On a rich-text message the styling delimiters are NOT included here; see formatted_text.

Markdown for a rich-text (bold/italic/underline/strikethrough) message. Omitted entirely when the message carries no styling, so its presence is how you detect rich text. Present in both directions: on an outbound send made with format: "markdown", and on an inbound iMessage whose sender styled their text — so styling a customer applied in Messages arrives here even though your integration never asked for it. Always a normalized re-serialization of the message's actual styling rather than an echo of the source string: bold is spelled **, italic *, underline ++, strikethrough ~~, and any character that would otherwise read as a delimiter is backslash-escaped. Re-sending this value verbatim with format: "markdown" reproduces the same styled message. Blooio iMessage only. This is the SAME field delivered on the message webhooks, so a message reads identically via REST or webhook.

Delivery lifecycle state: queued (accepted, awaiting dispatch), sent (handed to the channel; protocol resolves around here), delivered (delivery receipt received), read (read receipt received), failed (see error), superseded (row replaced by an idempotency retry or a poll-vote supersession). Inbound messages surface via the event feed / webhooks with received.

Structured interactive content, present on interactive messages. For an inbound reply this is the customer's actual selection (role: reply): kind (quick_reply/list_picker/time_picker/form/…), chosen (the selected option titles / time slots / flattened answers) and, for Form Messages, a structured responses array (per-page question + typed answers per §17.4) — not just a display string, and never null on an interactive reply. For an outbound send it is the prompt that was sent (role: prompt). The message's text remains a deterministic flattened convenience summary alongside this structure. This is the SAME object delivered on the message.received webhook, so a message reads identically via REST or webhook.

Present on imessage_app messages (custom app bubbles): the app's bundle_id, team_id and app_name, the app-state url its extension reads, caption / subcaption, and the bubble's session_id. The same object the message webhooks carry.

Apple Messages for Business only: the entry-point intent / group Apple attached to this message when the customer opened the conversation from a link or QR code. Present only on that message.