# Introduction

> Durable scheduled HTTP delivery — a destination plus a time, delivered and retried until it lands, never silently lost.

**SchedStack** is durable scheduled HTTP delivery. You hand it a **destination and a
time** — one-shot or recurring — and it owns everything from accepting the request to
confirming delivery: **retried until it lands, never silently lost.**

It's the durable timer that stateless agents and functions can't hold on to themselves —
**durable scheduling for the agentic era.**

```bash
# A destination + a time. That's the whole API.
curl -X POST https://api.schedstack.com/v1/schedules \
  -H "Authorization: Bearer sk_test_…" \
  -H "Content-Type: application/json" \
  -d '{"endpoint": "https://example.com/hook", "delay": "24h"}'
```

In 24 hours, SchedStack signs and POSTs to your endpoint. If it fails, SchedStack retries
on a backoff. If it exhausts retries, the delivery lands in your dead-letter view — not in
the void.

## The four pillars

    A first-class MCP server with forgiving timing inputs — a duration (`"in 2h"`), an
    ISO 8601 / RFC 3339 time, or `cron` — so agents can schedule deliveries and preview the
    next fire times before committing.

    One durable scheduling primitive — simple to adopt, easy to reason about. No workflow
    DSL, no orchestration runtime, no background workers for you to operate.

    A spec-first REST API, a `sched` CLI, and an interactive reference you can call live.

    Every accepted delivery either succeeds or becomes visible in your dead-letter view.
    Deliveries are signed when a signing secret is configured; every request carries a
    stable idempotency key.

## The guarantees

Two guarantees define the contract. Read both before you build against it — the second one
has a tradeoff you own.

### No silent loss

Once SchedStack returns `201` for a schedule, that delivery is durable. It will succeed, or
it will end up in your dead-letter view where you can inspect every attempt and replay it.
A delivery never disappears between "accepted" and a terminal outcome.

### At-least-once, made safe — you dedup

SchedStack delivers **at least once**. Retries, failover, and reclaim after a node restart
mean your endpoint can receive the **same delivery more than once**. That is by design:
choosing at-least-once over at-most-once is what makes "never silently lost" possible.

Two mechanisms make redelivery safe, and using them is your responsibility:

- **`Sched-Signature`** — when a signing secret is configured (on the endpoint profile, or
  as a project default), each request is HMAC-signed (`t=…,v1=…`) with that endpoint or
  project secret, alongside a `Sched-Timestamp`. Verify it to confirm the request came from
  SchedStack and is not replayed. Without a configured secret, deliveries are sent
  **unsigned** with no `Sched-Signature` header. See
  [Verify signatures](/docs/guides/verify-signatures/).
- **`Idempotency-Key`** — every request carries a stable key (also `Sched-Delivery-Id`).
  Dedup on it so a redelivered request is a no-op on your side.

**At-least-once means *you* dedup**

SchedStack does not guarantee exactly-once delivery — no networked system honestly can.
Make your endpoint idempotent: verify the signature, then key on `Idempotency-Key`. This is
the single most important thing to get right.

### The accuracy SLO: 100–300 ms, dispatch-initiation

SchedStack publishes a **100–300 ms p99 dispatch-initiation SLO**. Read that phrase
literally:

- **Dispatch-initiation, not delivery completion.** It measures `first byte out − scheduled
  time` — when SchedStack starts the outbound request, not when your endpoint finishes
  responding. Network and your server's latency are outside it.
- **Live first-attempts only.** The published number is computed over first attempts
  (`Sched-Attempt: 1`) in live mode. It **excludes** retries, reclaim/recovery fires,
  breaker/budget deferrals, and sub-floor near-instant schedules.

SchedStack controls *initiation* precisely; it does not control your receiver's response
time. Build for the guarantee you actually get: prompt, accurate dispatch — plus
retry-until-it-lands for everything after the first byte.

## Where to go next

    Schedule your first durable delivery and watch it land, in under five minutes.
    [Start here →](/docs/quickstart/)

    Schedules, deliveries, attempts, retries, dead-letter, and replay — the model behind
    the API. [Read the model →](/docs/concepts/overview/)

    Validate `Sched-Signature` and dedup on `Idempotency-Key` — the safe at-least-once
    recipe. [Verify deliveries →](/docs/guides/verify-signatures/)

    Let agents schedule, preview, and replay deliveries over MCP.
    [Connect an agent →](/docs/mcp/)

    The full `/v1` surface — schedules, deliveries, attempts — interactive and live.
    [Open the reference →](/docs/api/)

**Design-partner phase**

SchedStack is live in production and onboarding design partners by hand. There's no
self-serve signup yet — keys are issued directly. If you have an `sk_test_…` or
`sk_live_…` key, the [Quickstart](/docs/quickstart/) is everything you need to reach your
first delivery.