Are Slack webhooks deprecated?
No. Incoming webhooks created through a Slack app are current, documented, and the way Slack tells you to post messages into a channel from an outside system. What is deprecated is the older custom integrations mechanism, including the legacy Incoming WebHooks integration and outgoing webhooks. Existing URLs still deliver, but new work should go through an app.
Two things share the name "Slack webhook"
The confusion comes from Slack having shipped incoming webhooks twice. The original version was a custom integration: an admin added it from the workspace's integrations page, picked a channel, and got a URL. The current version is a feature of a Slack app, where you create the app at api.slack.com/apps, turn on Incoming Webhooks, and add a webhook to the workspace.
Both hand you a webhook URL that starts with https://hooks.slack.com/services/, and both accept the same JSON body, which is why so many people cannot tell whether the one in their config file is the deprecated kind. Slack's own documentation now describes custom integrations as legacy and points every new setup at apps.
What Slack has actually retired
Custom integrations as a family are the deprecated part. That covers legacy incoming webhooks, outgoing webhooks, custom slash commands, and legacy bot users. Slack has kept existing ones running rather than switching them off, so a legacy URL wired up years ago probably still posts messages today. The practical cost of staying on one is not a sudden outage, it is that the feature receives no new capabilities and that workspace admins increasingly restrict the integrations page.
Outgoing webhooks are the case worth acting on. They were the mechanism for Slack to POST to your server when a message matched a trigger word, and they only ever worked in public channels. The replacement is the Events API, which subscribes your app to specific event types, signs every request, and works across channel types. If something in your stack still listens on an outgoing webhook, that is the migration to schedule.
How to tell which kind you have
Open api.slack.com/apps and look for an app that owns the webhook. If you find it listed under that app's Incoming Webhooks page, you are on the supported path and there is nothing to do. If no app claims it, check the workspace's custom integrations page at https://<your-workspace>.slack.com/apps/manage/custom-integrations, where legacy incoming and outgoing webhooks are managed.
Behavior gives it away too. Legacy custom integrations let the payload override the destination with a channel field, and change the sender with username and icon_emoji. A webhook created through an app ignores all three: it posts as the app, to the channel you selected when you installed it. Code that sets "channel": "#alerts" and lands somewhere else is code talking to an app webhook.
Migrating a legacy webhook
The move is mechanical and takes a few minutes per URL. Create a Slack app, enable Incoming Webhooks, add a webhook to the workspace, and select the channel. Our guide to getting a Slack webhook URL walks through each screen. Swap the new URL into your configuration, confirm a test message arrives, then delete the old integration so nothing keeps posting from an unowned source.
Two things to plan for. Each app webhook is bound to one channel, so a legacy integration that fanned messages out by setting channel per request becomes several URLs, one per destination. And because messages now post under the app's name and icon rather than whatever the payload asked for, set the app's display name and avatar to match what your team is used to seeing.
The other side of the problem
Posting into Slack is the easy direction: one URL, one POST, no state to keep. Receiving webhooks is where the work lives, because your own endpoint has to verify signatures, respond fast enough to avoid a timeout, and stay correct when the same event arrives twice.
That asymmetry is worth remembering if you are the one designing an integration rather than consuming one. Sending events to your customers means owning retries, signature schemes, delivery logs, and the support tickets that follow when any of them misbehave. Svix provides that infrastructure as a service, and Svix Ingest handles the receiving side when you are the one taking events in.