---
title: Is Stormedo a fit?
description: Decide when managed outbound HTTP delivery is the right boundary and when another tool is a better 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](/docs/concepts/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](/docs/concepts/idempotency/) and [Delivery verification](/docs/concepts/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](/docs/get-started/first-request/). Review [Plans and limits](/docs/reference/plans-and-limits/) before choosing a production plan.