Incoming webhooks are a simple way to post messages from apps into Slack.
Because we strongly recommend you do not use legacy custom integrations anymore, you should instead use the similar feature in Slack apps. Our guide to Getting Started with incoming webhooks will walk you through the process of enabling this functionality in a Slack app.
If you previously created any incoming webhooks using legacy integrations, you should switch to using the same functionality with a Slack app instead. To do this you need to follow the Getting started with incoming webhooks guide and create new webhooks to replicate your existing ones.
The majority of your legacy code for sending messages using incoming webhooks should continue to work within a Slack app without much modification; the only thing you can no longer do is customize the destination channel and author identity at runtime.
Though we recommend that all legacy custom integrations should migrate to Slack apps, we also understand that some will still need to maintain older integrations. This section contains any information about using incoming webhooks that is specific to the legacy implementation.
If you need to configure your legacy integrations, you can access the Integrations management pages here.
While you can use legacy incoming webhooks to post messages, they do not have access to interactive messages features. To make your messages interactive, you'll need to create an incoming webhook with a Slack app instead.
Please note: it's not possible to send files via webhook. The files.upload API method is the method of choice for this task.
Here is a reference list of fields that are used with legacy incoming webhooks to provide runtime customization:
username - override the legacy integration's default name.icon_emoji - an emoji code string to use in place of the default icon.icon_url - an icon image URL string to use in place of the default icon.channel - override the legacy integration's default channel. This should be an ID, such as C8UJ12P4P.