Introduction

A plain Slack incoming webhook is not a good direct subscriber for an AWS SNS HTTPS subscription. SNS expects the subscriber endpoint to handle a confirmation handshake, while a Slack webhook expects a ready-to-post Slack message payload and does not confirm SNS subscriptions for you.

Why Direct SNS to Slack Breaks

When you create an SNS subscription for an HTTPS endpoint, SNS first sends a SubscriptionConfirmation request. A real SNS-aware subscriber must confirm that request by following the SubscribeURL or by calling the confirmation API with the provided token.

Slack incoming webhooks do not do that. They are designed to accept Slack message payloads such as:

{
  "text": "Build completed"
}

They are not designed to receive SNS control messages and then turn themselves into confirmed subscribers.

That creates two separate mismatches:

• the SNS confirmation handshake is not handled
• even after confirmation, the SNS JSON envelope is not the message format Slack expects

What SNS Actually Sends

Before delivery begins, SNS sends a message with a shape like this:

1{
2  "Type": "SubscriptionConfirmation",
3  "MessageId": "...",
4  "Token": "...",
5  "TopicArn": "arn:aws:sns:...",
6  "Message": "You have chosen to subscribe...",
7  "SubscribeURL": "https://sns...."
8}

A Slack webhook will not visit the SubscribeURL on its own, and it will not magically become a valid SNS subscriber just because it received an HTTP POST.

That is the reason direct subscription usually fails in practice.

The Reliable Pattern: Use Lambda as a Bridge

The cleanest design is:

1. subscribe a Lambda function to the SNS topic
2. let SNS invoke Lambda directly
3. have Lambda format and post a Slack message to the webhook URL

That avoids the HTTPS confirmation issue entirely because SNS natively supports Lambda subscriptions.

Example Lambda in Python:

1import json
2import os
3import urllib.request
4
5SLACK_WEBHOOK_URL = os.environ["SLACK_WEBHOOK_URL"]
6
7
8def lambda_handler(event, context):
9    for record in event.get("Records", []):
10        sns = record["Sns"]
11        subject = sns.get("Subject", "SNS notification")
12        message = sns["Message"]
13
14        payload = {
15            "text": f"*{subject}*\n{message}"
16        }
17
18        request = urllib.request.Request(
19            SLACK_WEBHOOK_URL,
20            data=json.dumps(payload).encode("utf-8"),
21            headers={"Content-Type": "application/json"},
22            method="POST",
23        )
24
25        with urllib.request.urlopen(request) as response:
26            print(response.status)
27
28    return {"statusCode": 200}

This pattern is simple, debuggable, and aligned with how both systems want to be used.

If You Really Use an HTTPS Endpoint

If you want SNS to deliver to HTTPS first, use an endpoint you control, not the Slack webhook directly. That endpoint must:

• detect SubscriptionConfirmation
• confirm the subscription
• handle later Notification messages
• translate the SNS payload into Slack's webhook format

At that point, you have built a bridge service. That can be useful if you already have an API service for other reasons, but it is more moving parts than the Lambda pattern for most teams.

Format Translation Is Still Required

Even if you solved the confirmation problem, SNS and Slack still do not speak the same payload language.

SNS sends an envelope with fields such as:

• 'Type'
• 'TopicArn'
• 'Subject'
• 'Message'

Slack expects a Slack-oriented message body, often containing text or Block Kit fields.

So some translation layer is required anyway. That is another reason direct SNS-to-Slack webhook wiring is usually the wrong design.

Security and Operational Considerations

A bridge layer also gives you a place to add:

• message filtering
• formatting rules
• retry handling
• secret management for the Slack webhook URL

If you hardwire an external webhook directly into an infrastructure notification path, you lose control over those concerns. A small Lambda function is often enough to restore that control.

Common Pitfalls

The most common mistake is assuming Slack will confirm the SNS HTTPS subscription automatically. It will not.

Another issue is solving only the confirmation step and forgetting that SNS notification payloads still need translation into Slack's message format.

People also sometimes build a custom HTTPS endpoint but fail to branch on SubscriptionConfirmation versus Notification. Without separate handling, the subscription never becomes active.

Finally, do not expose a bridge endpoint casually without verifying SNS message authenticity if you operate it as a public HTTPS receiver.

Summary

• A plain Slack incoming webhook is not a confirmation-aware SNS HTTPS subscriber.
• Direct SNS-to-Slack webhook subscriptions usually fail at the confirmation or payload-format stage.
• The cleanest solution is to subscribe Lambda to SNS and let Lambda post formatted messages to Slack.
• A custom HTTPS endpoint can work, but only if it explicitly handles SNS confirmation and message translation.
• Treat SNS confirmation and Slack formatting as separate integration concerns.