13

I am trying to send messages from several outer sources to a specific channel, which is private and belongs to myself only. The username should be the name of source, not my ID.

I found there are two ways to do such a similar function: Incoming Webhooks and chat.postMessage

I have already practiced these two, which seems no difference between them.

However, in Incoming Webhooks, a statement says:

You can't use Incoming Webhooks with Workspace Apps right now; those apps can request single channel write access and then use chat.postMessage in the Web API to post messages, providing very similar functionality to Incoming Webhooks.

What does it mean?

To my work, which one is better?

ShanChe Wu
  • 315
  • 2
  • 8
  • Thanks both for providing helpful advice. My work unit just began to use slack so it's likely that some slack technical issues will come up in the near future. I will post them on stackoverflow to discuss with professionals like you. Thanks! – ShanChe Wu Apr 30 '19 at 11:00
  • One more point I would add here is with chat.postMessage it won't work until the user installs the app inside of the channel. That is not the case with the incoming webhooks. – abhij89 Apr 06 '22 at 08:55

2 Answers2

8

with chat.postMessage() you send a message to a specific channel, often you do that in response to a users action. You will need the token to verify the postMessage Request which you receive when the user installs your app. Incoming webhooks are often used to post general information, e.g. patch notes or general announcements. As far as I know, you don't need the token since there is a verification behind that Url. so the webhook url is bound to a specific channel, which is specified through the user. With chat.postMessage you can post messages anywhere (depending on your permissions, maybe not in private channels or direct messages)

Ben Denger
  • 228
  • 1
  • 11
  • Thanks for your sharing and I agree with your point. Thus it depends on channel field I think.. – ShanChe Wu Apr 29 '19 at 08:54
  • are you building a public application or will you just use it internally? – Ben Denger Apr 29 '19 at 08:56
  • if you just use it internally, I would just use the webhook. for my slack app, it was better to use chat.postMessage since we are posting messages where the destinations can be defined by different users. but if it should be just an aggregation of other datasources to a specific channel, Webhooks should do their job – Ben Denger Apr 29 '19 at 08:59
  • Thanks for your advice! Actually 5 types of messages are sent into their corresponding channels respectively. Messages are sent by myself only, and I am also the owner of these channels. In this aspect above, I think chat.postMessage is more proper. However, we are worried about the security issue resulting from the leakage of token accidentally. It might be more risky to use chat.postMessage compared with incoming webhooks? – ShanChe Wu Apr 29 '19 at 16:04
  • 1
    security wise it doesnt make a huge difference i think, even when you should always try not to expose them, when it happens, you can regenerate the token, or revoke the webhook in your apps settings. In fact it happend to me once that i exposed my token in a public github repo, and a scanner of slack detected that and revoked the token automatically! to be honest i dont know if they do that as well for webhooks – Ben Denger Apr 29 '19 at 17:23
  • @ShanCheWu If you agree that you question has been answered please consider marking one as solution (click the green checkmark). And feel free to post another question if you have more topics. TY – Erik Kalkoken Apr 30 '19 at 09:58
  • any idea what is the rate limit for `chat.postMessage` in a workspace, it is not made quite clear in the docs – Yogendra Apr 05 '23 at 08:53
8

Adding to what Ben said:

Incoming webhooks are limited in their functionality. They are great if you need an easy way to send a message that does not require a token, but in general the API method (chat.postMessage) is the better choice. It is more flexible (e.g. not fixed to one channel) and provides the full functionality (e.g. you get the ID for a message and can later update it).

Workspace apps / tokens where a new functionality that allowed apps to be installed in one channel only (among other things). It never left its beta stage and can be safely ignore for further development.

Erik Kalkoken
  • 30,467
  • 8
  • 79
  • 114
  • Thanks for your advice! There is one further question about token of chat.postMessage. I am using [Legacy token generator](https://api.slack.com/custom-integrations/legacy-tokens) to generate the token for chat.postMessage. it states that "Legacy tokens are an old method of generating tokens for testing and development. Because we strongly recommend you do not use legacy custom integrations anymore, you should instead use Slack apps to quickly generate tokens, without OAuth, by installing your app to your own team." Have you ever used this lagacy token on chat.postMessage as well? – ShanChe Wu Apr 29 '19 at 16:22
  • yes. legacy tokens work perfectly with any API method incl. chat.postMesssage – Erik Kalkoken Apr 29 '19 at 19:32
  • @ErikKalkoken, Does webhook get rate limited? Web API seems to be limited according to doc. Say if I have a bot installed and there could be at most 10 users talk to the bot at the same time, how should I respond? with chat.postMessage API or using some incoming webhook? – anuni Jul 20 '19 at 08:01
  • No the same rate limit applies to webhooks and chat.postMessage of posting max 1 message per second. So I would always recommend using the API endpoint due to its better functionality. See here for the rate limit: https://api.slack.com/docs/rate-limits#limits_when_posting_messages – Erik Kalkoken Jul 20 '19 at 10:08