Is Stormedo a fit?

Stormedo is a managed outbound HTTP delivery service. Your application hands off a request, receives 202 Accepted after durable acceptance, and continues without waiting for the destination. Stormedo owns the later delivery attempts, retry timing, scheduling, and operational history.

Stormedo is a good fit when

• An outbound HTTP call should continue even if your application process restarts.
• A destination can be temporarily unavailable and automatic retries are appropriate.
• You need one-time delayed delivery without keeping an application worker alive.
• You need recurring HTTP delivery using an interval or cron schedule.
• You want request and attempt history without operating queue infrastructure.
• The receiving service can authenticate signed deliveries and safely deduplicate them.

Common examples include webhooks, asynchronous partner API calls, delayed notifications, inventory synchronization, cleanup callbacks, and recurring HTTP-based maintenance triggers.

Stormedo is not a good fit when

• The destination response must be returned synchronously to the current user request.
• You need arbitrary customer code to run inside the delivery system.
• You need a multi-step workflow engine with branching, approvals, or durable application state between steps.
• The receiver cannot tolerate duplicate attempts or cannot make its business side effects idempotent.
• You need an exactly-once delivery guarantee. Stormedo provides at-least-once delivery.
• The work is not naturally represented as an outbound HTTP request.

Compare the operating models

Approach	You operate	Best for	Main tradeoff
Direct HTTP call	Application request and destination call	Fast synchronous calls where the destination is reliable	Your application owns timeouts, retry safety, and failure recovery
Queue and workers	Queue, workers, retry policy, scheduler, storage, and monitoring	Arbitrary background code and complex internal processing	Maximum control with a larger operational surface
Stormedo	The producer and receiving endpoint	Durable immediate, delayed, or recurring HTTP delivery	Work must cross an HTTP boundary and receivers must handle at-least-once delivery

The reliability contract

Stormedo separates acceptance from delivery:

1. Your application submits an outbound HTTP request.
2. Stormedo validates and durably accepts it.
3. The API returns 202 Accepted with a stable request ID.
4. Delivery continues independently and temporary failures can be retried.
5. Every completed attempt remains available in request history for the plan’s retention window.

Durable acceptance does not mean the destination has already processed the request. Read Request lifecycle for the complete state model.

Duplicate-safe processing is required

A destination can successfully process an attempt before Stormedo records the response. If execution is interrupted in that window, Stormedo may send the same logical request again.

Use both idempotency boundaries:

• Send a stable publisher Idempotency-Key so submission retries do not create new request resources.
• After verifying the delivery, store Stormedo-Request-Id before or atomically with the receiver’s business side effect.

Read Idempotency and Delivery verification before processing production deliveries.

Evaluation checklist

Stormedo is likely the right boundary if all of these are true:

• The work can be expressed as an outbound HTTP request.
• The caller should move on after durable acceptance.
• Temporary destination failures should be retried.
• The receiver can verify and deduplicate deliveries.
• A managed delivery log is more useful than operating your own queue and workers.

If those conditions hold, continue with Send your first request. Review Plans and limits before choosing a production plan.