Features

Examples

Resources

© Pipedream, Inc. 2023

Incoming Webhooks are a simple way to post messages from apps into Slack. Creating an Incoming Webhook gives you a unique URL to which you send a JSON payload with the message text and some options. You can use all the usual formatting and layout blocks with Incoming Webhooks to make the messages stand out.

If you're looking for the Help Center article on using webhooks with Workflow Builder, head over here. Otherwise, read on!

We're going to walk through a really quick 4-step process (if you've already done some of these things it'll be even easier) that will have you posting messages using Incoming Webhooks in a few minutes:

You won't get very far without doing this step, but luckily it's very simple, we even have a nice green button for you to click:

Create your Slack app

Pick a name, choose a workspace to associate your app with (bearing in mind that you'll probably be posting lots of test messages, so you might want to create a channel for sandbox use), and then click Create App. If you've already created one, you can use it too, also have a cookie 🍪.

After creating, you'll be redirected to the settings page for your new app (if you are using an existing app, just load its settings via your app's management dashboard).

From here select the Incoming Webhooks feature, and click the Activate Incoming Webhooks toggle to switch it on. If you already have this activated, well you deserve another cookie 🍪.

Now that Incoming Webhooks are enabled, the settings page should refresh and some extra options will appear. One of those options will be a really helpful button marked Add New Webhook to Workspace, and you should click it.

What this button does is trigger a shortcut version of the installation flow for Slack apps, one that is completely self-contained so that you don't have to actually build any code to generate an Incoming Webhook URL. We'll show how you can generate webhooks programmatically later, but for now you'll see something like the following screen:

Go ahead and pick a channel that the app will post to, and then click to Authorize your app.

You'll be sent back to your app settings, and you should now see a new entry under the Webhook URLs for Your Workspace section, with a Webhook URL that'll look something like this:

That URL is your shiny new Incoming Webhook, one that's specific to a single user, and a single channel. We've kind of run out of cookies, but nice work anyway!

Let's see how you can actually use that webhook to post a message.

Keep it secret, keep it safe. Your webhook URL contains a secret. Don't share it online, including via public version control repositories. Slack actively searches out and revokes leaked secrets.

Later in this doc we'll explain how to make your messages more expressive or interactive, but for right now something simple will do, so we're going to use that old standby - "Hello, world".

After all this build up, you might think posting a message will be really complicated, but it's very simple. Just make an HTTP POST request like this:

The URL that you're making the POST request to should be the same URL you generated in the previous step.

That's it! Go and check the channel that your app was installed into, and you will see that the "Hello, World" message has been posted by your app.

You can use this in a real Slack app without much change, just substituting your favorite HTTP Request library for cURL, but structuring all the requests in the exact same way. You will also need to pay attention to some details we've outlined below when you're distributing your app.

Incoming Webhooks do not allow you to delete a message after it's posted. If you need a more complex chat flow, including message deletion, call chat.postMessage.

Great work, you've set up Incoming Webhooks for your Slack app and made a successful test call, and you're ready to start making those messages more interesting and useful. Also, we baked some extra cookies to celebrate 🍪🍪🍪🍪.

Incoming Webhooks conform to the same rules and functionality as any of our other messaging APIs. You can make your posted messages as simple as a single line of text, or make them really useful with interactive components.

The process of using all these extras and features is basically the same as the one explained above. The only difference is the JSON payload that you send to your webhook URL will contain other fields in addition to text. Here's a more advanced HTTP request example that you can use with the same webhook url that you used above:

This example uses Block Kit visual components to make the message more expressive and useful.

We have some fantastic docs that explain how to use text formatting and Block Kit to make your messages more interesting and interactive, so please dive into our overview of message composition.

You cannot override the default channel (chosen by the user who installed your app), username, or icon when you're using Incoming Webhooks to post messages. Instead, these values will always inherit from the associated Slack app configuration.

You can use Incoming Webhooks to make your message appear as a reply in a thread. Read our guide to threading messages to see the process.

In the guide above we showed you how to quickly generate a webhook URL through your app settings UI, but when you're distributing your app (for use by non-collaborators), you'll need a way for it to generate those URLs on the fly.

Fortunately, Incoming Webhooks can be easily generated during the standard OAuth install flow.

If you are going to distribute your app, it's likely you're already planning to use the OAuth process anyway. Below we'll cover the adjustments you'll need to make to that process to enable Incoming Webhooks.

As part of the install process, your app defines a set of initial permission scopes to request from a user. Whether you're using the Slack button to provide a link for users to install your app or your own custom OAuth redirect, there will be a scope parameter that sets this initial list of permissions.

To generate Incoming Webhook URLs, make sure you include the incoming-webhook permission in that scope list. When you do, users will see an additional permission on the Authorize screen that lets them pick the channel where Incoming Webhooks will post to, as shown above.

Once a user installs your app, and your app has completed the OAuth verification code exchange, you'll receive a JSON response like this:

You can see that this OAuth response contains an incoming_webhook object, and right there in the url field is your brand new Incoming Webhook URL. You can now go ahead and use this URL to post a message, as demonstrated above. Here's a full explanation of all the fields in this incoming_webhook object:

Though in most cases you'll receive a "HTTP 200" response with a plain text ok indicating that your message posted successfully, it's best to prepare for scenarios where attempts to publish a message will fail.

Incoming webhooks may throw errors when receiving malformed requests, when utilized webhook URLs are no longer valid, or when something truly exceptional prevents your messages from making it through to channels and users.

Incoming webhooks return more expressive errors than our Web API, including more relevant HTTP status codes (like "HTTP 400 Bad Request" and "HTTP 404 Not Found"). These are described in our changelog: Changes to errors for incoming webhooks.

Common errors you may encounter include:

Webhooks do not work with org-wide apps. Use our other messaging tools, including chat.postMessage, instead.