This method attaches Slack app unfurl behavior to a specified and relevant message. A user token is required as this method does not support bot user tokens.
The first time this method is executed with a particular ts and channel combination, the valid unfurls attachments you provide will be attached to the message. Subsequent attempts with the same ts and channel values will modify the same attachments, rather than adding more.
Timestamp of the message to add unfurl behavior to.
URL-encoded JSON map with keys set to URLs featured in the the message, pointing to their unfurl message attachments.
Provide a simply-formatted string to send as an ephemeral message to the user as invitation to authenticate further and enable full unfurling behavior
Set to true or 1 to indicate the user must install your Slack app to trigger unfurls for this domain
Send users to this custom URL where they will complete authentication in your app to fully trigger unfurling. Value should be properly URL-encoded.
The provided ts value must correspond to a message in the specified channel. Additionally, the message must contain a fully-qualified URL pointing to a domain that is already registered and associated with your Slack app.
The unfurls parameter expects a URL-encoded string of JSON. Unlike chat.postMessage's attachments parameter, it does not expect a JSON array but instead, a hash keyed on the specific URLs you're offering an unfurl for. Each URL can have a single attachment, including message buttons.
The user_auth_required parameter is optional. By providing a 1 or true value, it will require the user posting the link first authenticate themselves with your app. See also the authenticated unfurling docs.
To point users to a specific page on your server to authenticate, pass a valid URL using the user_auth_url parameter. When sending this parameter via application/x-www-form-urlencoded GETs or POSTs, values must be URL-encoded such that https://example.com/onboarding?user_id=xxx becomes https%3A%2F%2Fexample.com%2Fonboarding%3Fuser_id%3Dxxx.
Or, you can send an ephemeral message to that user by providing a simple user_auth_message value. Simple slack message formatting like *bold*, _italics_, and linking is supported, so you can wrap your custom URLs in a blanket of situationally accurate, actionable text.
Specifying user_auth_url or user_auth_message will automatically imply user_auth_required being set to true. If both user_auth_url and user_auth_message are provided, user_auth_message takes precedence.
As you can see, we provide a minimal positive response when your unfurl attempt is successful. When it is not, you'll receive one of the errors below and ok will not be false.
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.
The URL cannot be unfurled, perhaps due to administrative blacklists on the domain.
A record of your app being allowed to unfurl for this workspace could not be found.
The request is missing the unfurls parameter.
No authentication token provided.
Invalid authentication token.
Authentication token is for a deleted user or workspace.
The workspace token used in this request does not have the permissions necessary to complete the request.
This method cannot be called by a bot user.
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.