A message was sent to a channel

Facts

Works with

RTMEvents API

A message can be delivered from multiple sources:

  • They are returned via calls to conversations.history.
  • They are sent via the Real Time Messaging API when a message is sent to a channel to which you subscribe. This message should immediately be displayed in the client.

Example:

{
	"type": "message",
	"channel": "C123ABC456",
	"user": "U123ABC456",
	"text": "Hello world",
	"ts": "1355517523.000005"
}

The channel property is the ID of the channel, private group, or DM channel this message is posted in. The user property is the ID of the user, the text property is the message, and ts is the unique (per-channel) timestamp. Messages can also include an attachments property, containing a list of attachment objects.

If the message has been edited after posting, it will include an edited property, which includes the user ID of the editor and the timestamp for when the edit occurred. The original text of the message is not available.

Example:

{
	"type": "message",
	"channel": "C123ABC456",
	"user": "U123ABC456",
	"text": "Hello, world!",
	"ts": "1355517523.000005",
	"edited": {
		"user": "U123ABC456",
		"ts": "1355517536.000001"
	}
}

Message events in the Events API

In the Events API, the exact message event is defined differently, and the specific event you subscribe to also dictates what scopes your app needs: for example, private channels require the groups:history scope. Depending on your associated OAuth scope or the channels your bot user belongs to, you must subscribe to one of the following events:

  • message.channels - for messages appearing within channels. Will only send message events from public channels to your app.
  • message.im - for messages appearing within direct messages.
  • message.groups - subscribe to this event if you want message events from private channels.
  • message.mpim - for messages appearing within multiparty direct messages.

The semantics for the events are the same — you're still receiving an event of type message.

Not all message subtypes are deliverable in the Events API.

Message subtypes

Unlike other event types, message events can have a subtype. For example, this is a channel join message:

{
	"type": "message",
	"subtype": "channel_join",
	"text": "<@U123ABC456|bobby> has joined the channel",
	"ts": "1403051575.000407",
	"user": "U123ABC456"
}

They are structured in this way so that clients can either support them fully by having distinct behavior for each different subtype, or they can fallback to just displaying the text of the message. The full list of message subtypes is below.

Loading events

Hidden subtypes

Some subtypes have a special hidden property. These indicate messages that are part of the history of a channel, but should not be displayed to users. Examples include records of message edits or deletes:

{
	"type": "message",
	"subtype": "message_deleted",
	"hidden": true,
	"channel": "C123ABC456",
	"ts": "1358878755.000001",
	"deleted_ts": "1358878749.000002",
	"event_ts": "1358878755.000002"
}

Hidden messages will not appear as the latest property on channel, group or im objects. They will also not return in calls to conversations.history.

Stars, pins, and reactions

Messages can have several extra properties depending on whether or not they have been starred, pinned, or reacted to:

{
	"type": "message",
	"channel": "C123ABC456",
	"user": "U123ABC456",
	"text": "Hello world",
	"ts": "1355517523.000005",
	"is_starred": true,
	"pinned_to": ["C024BE7LT", ...],
	"reactions": [
		{
			"name": "astonished",
			"count": 3,
			"users": [ "U1", "U2", "U3" ]
		},
		{
			"name": "facepalm",
			"count": 1034,
			"users": [ "U1", "U2", "U3", "U4", "U5" ]
		}
	]
}

The is_starred property is present and true if the calling user has starred the message, else it is omitted.

The pinned_to array, if present, contains the IDs of any channels to which the message is currently pinned.

The reactions property, if present, contains any reactions that have been added to the message and gives information about the type of reaction, the total number of users who added that reaction, and a (possibly incomplete) list of users who have added that reaction to the message. The users array in the reactions property might not always contain all users that have reacted (we limit it to X users, and X might change) — however, count will always represent the count of all users who made that reaction (i.e. it may be greater than users.length). If the authenticated user has a given reaction then they are guaranteed to appear in the users array, regardless of whether or not count is greater than users.length.

When an event occurs, we will send an HTTP POST request to your Request URL. The outer payload is uniform across all Events API methods, and contains fields like team_id and event. Learn more