Deliver Webhooks Directly to SQS, EventBridge, Pub/Sub, and More

The Pattern Everyone Builds

You set up a webhook endpoint. It receives a POST, validates the signature, and immediately shoves the payload into a queue — SQS, Pub/Sub, Service Bus, whatever your stack uses. Then a consumer picks it up later for actual processing.

This is the standard pattern for handling webhooks at scale. And it means you're running an HTTP server whose only job is to be a middleman between the webhook sender and your queue.

What if you could skip that entirely?

Queue Destinations

Hookbase now delivers webhooks directly to managed queue and event bus services. No HTTP endpoint needed. Events go straight from our ingestion pipeline into your queue.

Supported services:

| Service | Provider | Use Case | |---------|----------|----------| | AWS SQS | Amazon | General-purpose message queuing | | AWS EventBridge | Amazon | Event-driven architectures with rules-based routing | | Google Cloud Pub/Sub | Google | GCP-native event streaming | | Azure Service Bus | Microsoft | Enterprise messaging with topics and subscriptions | | OCI Queue | Oracle | Oracle Cloud message queuing |

Setting up a queue destination takes 30 seconds — pick the service, enter your credentials, and point a route at it. Your existing sources, filters, and transforms all work the same way.

Why This Matters

No Endpoint to Maintain

You don't need to run a server, container, or Lambda just to catch webhooks and forward them. One less thing to deploy, monitor, and keep running.

Two Layers of Retry

This is where it gets interesting. When Hookbase delivers to your queue, you get redundant reliability:

1. Hookbase retries — If the queue service is temporarily unreachable (throttling, outage), we retry with exponential backoff. Circuit breakers, failover destinations, and dead letter queues all kick in.
2. Queue durability — Once the message lands in the queue, the cloud provider guarantees it stays there until your consumer processes it. SQS gives you up to 14 days of retention.

The only way you lose a webhook is if both Hookbase and your cloud provider are simultaneously down for the entire retry window. Even then, it lands in our DLQ for manual replay.

Native Backpressure

If your consumer falls behind, messages queue up naturally instead of timing out HTTP requests and triggering retries. The queue absorbs traffic spikes — that's what it's designed for.

How It Works Under the Hood

Each queue destination type uses the cloud provider's native API:

• SQS — AWS Signature V4 signed requests to the SendMessage API
• EventBridge — PutEvents API with customizable source and detail-type for rule matching
• Pub/Sub — JWT-based service account auth with the publish API
• Service Bus — SAS token authentication with the REST messaging API
• OCI Queue — Bearer token auth with the PutMessages API

All credentials are encrypted at rest using AES-256. No AWS SDK or cloud provider SDK is required — we sign and send requests directly from Cloudflare Workers using the Web Crypto API, keeping cold starts fast and bundle sizes small.

Transforms Still Work

Your JSONata, JavaScript, and Liquid transforms apply before the message reaches the queue. This means you can:

• Strip unnecessary fields to reduce message size
• Reshape the payload to match your consumer's expected format
• Extract specific values into message attributes for queue-level filtering

For EventBridge specifically, you can set custom source and detailType fields so your EventBridge rules can filter and route events without inspecting the payload.

FIFO Queue Support

For SQS FIFO queues, set a Message Group ID in your destination config. Hookbase automatically generates deduplication IDs from the payload hash, so you get ordered, exactly-once delivery without any extra work.

Getting Started

Queue destinations are available on Pro and Business plans. To set one up:

1. Go to Destinations → Add Destination
2. Select the Queue / Event Bus category
3. Choose your service (SQS, EventBridge, Pub/Sub, Service Bus, or OCI Queue)
4. Enter your credentials and configuration
5. Create a route pointing from your source to the new destination

Your first webhook will land directly in your queue within seconds.

What About Kafka?

We get asked about Kafka frequently. Kafka uses a binary TCP protocol that doesn't work from edge compute environments like Cloudflare Workers. For now, we recommend using managed Kafka services that offer REST APIs (like Confluent Cloud or Upstash Kafka) via an HTTP destination, or placing an SQS queue in front of your Kafka consumer.

If native Kafka support is important to your use case, let us know.

Cloud Storage Destinations Too

Queue destinations join our existing cloud storage destinations — Amazon S3, Cloudflare R2, Google Cloud Storage, and Azure Blob Storage — for batch archival and data lake ingestion. Between HTTP, queues, and storage, Hookbase can deliver your webhooks wherever your infrastructure lives.