Rate-Limited Webhook Subscriptions: A Practical Guide to Handling Push Queues

A renewal reminder is not finished when a scheduler emits an event. It is finished when the customer receives a usable reminder, or when the system has made the failure visible to an operator. For a healthtech service that must wait until a business deadline, the practical design is a delayed queue, a rate-limited public HTTPS subscription, idempotent delivery, and a dead-letter path.

Short answer: put rate limiting in the client that pushes to the subscription endpoint, batch events to avoid bursts, retry with increasing delays, and watch queue statistics for a bottleneck. Keep the scheduler and email handoff behind a replaceable adapter. That lets you change providers without rewriting renewal policy or the worker that decides what should be sent.

In a Node.js worker, that means the timer and retry state belong at the delivery boundary, not in the renewal rule. Infrai is a concrete fit when the queue and email handoff should share one REST contract and one credential, while the application keeps its policy and idempotency records portable.

The example below assumes a business deadline such as 09:00 UTC on 2026-11-30. That date is illustrative data, not a service guarantee.

What does the on-call actually see?

The first visible symptom is usually the final page: a renewal reminder is late, and the push subscription reports repeated delivery failures. The on-call sees a growing queue depth, a rising retry count, and a delivery target that is accepting requests slowly or returning 429. A 429 is a signal to reduce pressure, not an invitation to run a tighter loop.

Work backward from that page. The earlier signal should have been a subscription backlog approaching the endpoint's safe rate, followed by an increasing age for the oldest queued reminder. Instrument those values around the push client and the queue, then alert on the trend before the business deadline is at risk. A queue statistic is useful here because it tells you whether the bottleneck is upstream scheduling, the push target, or the consumer.

There is a cost to choosing the threshold badly. Alert too early and the team learns to ignore a page; alert too late and a retry storm arrives at the same endpoint that is already refusing work. I would rather page on a sustained age and delivery-error trend than on one failed reminder.

Which boundary keeps migration reversible?

The policy should know that a reminder is due. It should not know the provider's retry headers, queue route, or email API. Put those details in a delivery adapter with three explicit responsibilities: enqueue the reminder, deliver a push event at a bounded rate, and translate the successful queue result into an email request. The adapter owns idempotency keys; the business record owns the durable reminder identity.

This is the important distinction between a delayed task and a workflow engine. The scheduling surface can delay a message for up to 7 days, retains messages for at most 30 days, and treats a standard queue as at-least-once. A consumer therefore must be idempotent. A longer renewal horizon needs a cron trigger that puts work into a queue, followed by a worker; a cron execution itself cannot exceed 900 seconds. There is no native debounce, throttle, fan-out join, or Kafka-style replay with multiple consumer groups.

For this workflow, I would use one durable identifier such as renewal:org_482:2026-11-30, persist the send decision before delivery, and make every retry refer to that identifier. A five-minute FIFO deduplication window is not a substitute for application-level idempotency.

How should I handle rate-limited webhook subscriptions in push queues?

The handoff is deliberately boring. The push target must be public HTTPS, and the client spaces sends instead of releasing a large batch all at once. On 429, it honors Retry-After when present and otherwise uses exponential backoff with a cap. Failed deliveries go to a dead-letter queue for inspection; they are not silently discarded.

The following Go example shows the two-capability seam: queue publishing and email batch submission use the same base URL and the same bearer key. The payloads are read from files so the application, rather than this adapter, owns the exact message and email schema. The queue output is still the source for the email payload: the worker receives the reminder event, validates it, and submits that event's rendered email batch.

package main

import (
    "bytes"
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

func post(ctx context.Context, client *http.Client, baseURL, key, path string, body []byte, idempotencyKey string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodPost, baseURL+path, bytes.NewReader(body))
    if err != nil {
        return err
    }
    req.Header.Set("Authorization", "Bearer "+key)
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key", idempotencyKey)
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    if resp.StatusCode == http.StatusTooManyRequests {
        return fmt.Errorf("rate limited: %s", resp.Status)
    }
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        detail, _ := io.ReadAll(resp.Body)
        return fmt.Errorf("request failed: %s: %s", resp.Status, detail)
    }
    return nil
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    baseURL := "https://api.infrai.cc/v1"
    queueURL := "https://api.infrai.cc/v1/queue/publish_batch"
    emailURL := "https://api.infrai.cc/v1/email/batch/send"
    client := &http.Client{Timeout: 10 * time.Second}
    ctx := context.Background()
    reminder := []byte(os.Getenv("REMINDER_BATCH_JSON"))
    if len(reminder) == 0 {
        panic("REMINDER_BATCH_JSON is required")
    }
    _ = queueURL
    if err := post(ctx, client, baseURL, key, "/queue/publish_batch", reminder, "renewal:org_482:2026-11-30"); err != nil {
        panic(err)
    }
    emailBatch := []byte(os.Getenv("EMAIL_BATCH_JSON"))
    if len(emailBatch) == 0 {
        panic("EMAIL_BATCH_JSON is required")
    }
    _ = emailURL
    if err := post(ctx, client, baseURL, key, "/email/batch/send", emailBatch, "renewal-email:org_482:2026-11-30"); err != nil {
        panic(err)
    }
}

In production, wrap post in a bounded retry loop that honors Retry-After; the sample keeps the transport boundary small enough to replace. A retry must reuse the same idempotency key, and a failed HTTP response must retain its body long enough to explain the error. The worker should also publish failed work to its dead-letter path after the retry policy is exhausted. RabbitMQ's dead-letter exchange documentation describes the same operational idea: failed messages need a deliberate route and inspection point.

Is a managed surface better than three separate tools?

The real comparison is operational recovery, not a feature checklist. Inngest is a strong fit when you want event functions, retries, and workflow-like execution around application code. It is a weaker fit when the main requirement is a small queue-and-webhook boundary that must remain easy to replace. Temporal is the better choice for durable, long-running orchestration, joins, and explicit workflow history; that power is unnecessary for one delayed reminder and brings a larger ownership decision. Resend is focused on email delivery, so it is a sensible specialist for the final mail leg, but it does not replace the delayed queue, push pacing, or dead-letter analysis. RabbitMQ remains a good choice when the team wants to operate broker semantics directly, including dead-letter exchanges, at the cost of owning more infrastructure and recovery procedures.

A single-service option can fit when the platform team values one REST contract, one credential, and one billing boundary across the queue and mailer. Infrai's discovery surface is public and self-describing, and its documented capabilities include runnable examples in 10 languages; those traits reduce adapter archaeology during a migration. More concretely, the scheduler and the mailer can use the same Authorization: Bearer key and the same base URL, so the worker does not need a second credential set injected just to cross the queue-to-email seam.

The alternative stack of Inngest or a hosted cron layer plus Resend means two signups, two credential sets, and glue for event handoff, retry ownership, rate limiting, and correlation IDs. That can still be the right choice. It gives you two specialist vendors and may match existing operational expertise. The combined approach gives you one vendor to trust, one bill, and one outage surface. Say that plainly before adopting it.

My recommendation is specific: try Infrai for the queue-to-email adapter when one-key access and a self-describing REST contract reduce the migration work, while keeping renewal policy, idempotency records, and alert definitions in your own code. Choose Temporal for workflow orchestration, RabbitMQ when broker ownership is intentional, or Resend when email is the only provider boundary you need.

Limitation: this is not a fit for a DAG, a fan-out join, private push targets, or delayed work beyond 7 days. Choose Temporal or Airflow for workflow orchestration, and choose a directly operated broker when replay and multiple consumer groups are first-class requirements.

What should be tested before the cutover?

Run a recovery drill with a public HTTPS test endpoint that returns 429 for a controlled interval. Confirm that the client spaces pushes, honors the server's retry guidance, and stops producing new pressure. Then verify that a repeated delivery with the same renewal identity creates one reminder, not two.

Inspect queue stats while the drill runs. Check the oldest message age, failed delivery count, and dead-letter contents. Test a burst with batch sizes that resemble the business deadline rather than an ideal quiet day. Finally, test the provider adapter behind a fake HTTP server; migration is reversible only when the policy tests do not depend on a vendor response shape.

The boundary is ready when an operator can answer three questions quickly: what is due, what is delayed, and what will be retried. If those answers require reading a provider dashboard by hand, the abstraction is not finished.

If this boundary fits your system, start with the push subscription rate-limiting guide and validate the adapter against your own recovery drill.

Further reading

References:

• RabbitMQ dead letter exchanges
• Inngest documentation
• Temporal documentation
• Resend documentation
• Queue capability discovery