This method returns a portion of messages/events from the specified multiparty direct message channel.
To read the entire history for a multiparty direct message, call the method with no latest or
oldest arguments, and then continue paging using the instructions below.
The messages array up to 100 messages between latest and oldest. If
there were more than 100 messages between those two points, then has_more
will be true.
If a message has the same timestamp as latest or oldest it will not be
included in the list, unless inclusive is true. This allows a client to
fetch all messages in a hole in channel history, by calling channels.history
with latest set to the oldest message they have after the hole, and oldest
to the latest message they have before the hole. If the response includes
has_more then the client can make another call, using the ts value of the
final messages as the latest param to get the next page of messages.
If there are more than 100 messages between the two timestamps then the
messages returned are the ones closest to latest. In most cases an
application will want the most recent messages and will page backward from
there. If oldest is provided but not latest then the messages returned are
those closest to oldest, allowing you to page forward through history if
Messages of type "message" are user-entered text messages sent to the multiparty direct message channel, while other types
are events that happened within the multiparty direct message channel. All messages have both a type and a sortable
ts, but the other fields depend on the type. For a list of all possible events,
see the channel messages documentation.
If a message has been starred by the calling user, the is_starred property will be present and
true. This property is only added for starred items, so is not present in the majority of messages.
The is_limited boolean property is only included for free teams that have
reached the free message limit. If true, there are messages before the current
result set, but they are beyond the message limit.
This table lists the expected errors that this method could return.
However, other errors can be returned in the case where the service is down
or other unexpected factors affect processing. Callers should always
check the value of the ok params in the response.
Value passed for channel was invalid.
Value passed for latest was invalid
Value passed for oldest was invalid
No authentication token provided.
Invalid authentication token.
Authentication token is for a deleted user or workspace.
The method was passed an argument whose name falls outside the bounds of accepted or expected values. This includes very long names and names with non-alphanumeric characters other than _. If you get this error, it is typically an indication that you have made a very malformed API call.
The method was passed a PHP-style array argument (e.g. with a name like foo). These are never valid with the Slack API.
The method was called via a POST request, but the charset specified in the Content-Type header was invalid. Valid charset names are: utf-8iso-8859-1.
The method was called via a POST request with Content-Typeapplication/x-www-form-urlencoded or multipart/form-data, but the form data was either missing or syntactically invalid.
The method was called via a POST request, but the specified Content-Type was invalid. Valid types are: application/x-www-form-urlencodedmultipart/form-datatext/plain.
The method was called via a POST request and included a data payload, but the request did not include a Content-Type header.
The workspace associated with your request is currently undergoing migration to an Enterprise Organization. Web API and other platform operations will be intermittently unavailable until the transition is complete.
The method was called via a POST request, but the POST data was either missing or truncated.
This table lists the expected warnings that this method will return.
However, other warnings can be returned in the case where the service
is experiencing unexpected trouble.
The method was called via a POST request, and recommended practice for the specified Content-Type is to include a charset parameter. However, no charset was present. Specifically, non-form-data content types (e.g. text/plain) are the ones for which charset is recommended.
The method was called via a POST request, and the specified Content-Type is not defined to understand the charset parameter. However, charset was in fact present. Specifically, form-data content types (e.g. multipart/form-data) are the ones for which charset is superfluous.