How do I send a webhook to an SQS queue?

Create a Webhook Relay AWS service connection with an access key that has sqs:SendMessage, attach an SQS output (the full queue URL) to a bucket, then point your provider at the bucket's webhook URL. Every incoming webhook is published to the queue as a message — no consumer code required to enqueue.

Do I need to write a Lambda to put webhooks on SQS?

No. Webhook Relay publishes the webhook to SQS for you. You only need to write the consumer that reads from the queue — and you can add that whenever you like, since the messages buffer in SQS.

What IAM permission does Webhook Relay need?

For an SQS output, the access key needs sqs:SendMessage on the target queue. Credentials are encrypted at rest and scoped to your account; API responses never return the full secret.

How to Send Webhooks to AWS SQS (No Consumer Code)

Putting webhooks onto a queue is a common reliability pattern: accept the event fast, drop it on a queue, and process it asynchronously so a slow handler never causes the provider to retry or time out. The usual way to get there is to stand up an API Gateway + Lambda just to call SendMessage. With Webhook Relay Service Connections, you skip that — webhooks land in Amazon SQS directly.

How it works

Webhook Relay has service connections (your cloud credentials) and outputs (where to send data). When a webhook arrives in a bucket, Webhook Relay forwards it to every output attached to that bucket — including an SQS queue:

Provider --> Webhook Relay bucket --> SQS output --> your queue --> your consumer

No public Lambda, no consumer needed just to enqueue. Your own worker reads the queue on its own schedule.

1. Create an AWS service connection

In the dashboard, add a service connection for AWS with an access key and secret. The key only needs one permission for this:

{
  "Effect": "Allow",
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:us-east-1:123456789012:my-queue"
}

Secrets are encrypted at rest (AES-256-GCM) and never returned in full by the API.

2. Attach an SQS output to a bucket

Add an SQS output to the bucket that will receive your webhooks. The only required field is the full queue URL:

https://sqs.us-east-1.amazonaws.com/123456789012/my-queue

The region is auto-detected from the URL (an arn:aws:sqs:... ARN works too). From now on, every webhook delivered to the bucket is sent to the queue as a message.

3. Point your provider at the bucket URL

Use the bucket's public Webhook Relay endpoint as the webhook URL in Stripe, GitHub, Shopify, or any provider. Test it with curl:

curl -X POST https://your-webhook-relay-endpoint \
  -H 'Content-Type: application/json' \
  -d '{"event":"order.created","id":"ord_123"}'

The message appears in your SQS queue within seconds.

Why route webhooks through a queue

Absorb spikes. A burst of webhooks queues up instead of overwhelming your handler.
Decouple delivery from processing. Your consumer can be down for maintenance; messages wait in SQS.
Fan-in. Send webhooks from many providers into one queue and process them uniformly.
Retry safely. Combine with SQS visibility timeouts and a dead-letter queue.

Going further

Add a transformation to reshape or enrich the payload before it hits the queue.
Filter so only the events you care about are enqueued.
Send to multiple destinations at once — e.g. SQS for processing and S3 for an archive.
Prefer Google Cloud? See sending webhooks to Pub/Sub.

Inspect a webhook first or create a free account to wire up the SQS output.

Tunnels

Webhooks

User Management