Test & live modes

Every API key is bound to exactly one project and one mode: test or live. The mode is baked into the key prefix:

• sk_test_…: a test-mode key
• sk_live_…: a live-mode key

You pass the key as a bearer token, and the mode comes along with it. There is no mode parameter on any request. The key decides.

# A test-mode request: builds, schedules, and delivers against test data only.
curl https://api.schedstack.com/v1/schedules \
  -H "Authorization: Bearer sk_test_…" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "https://example.com/hooks/orders",
    "method": "POST",
    "body": "{\"order_id\":\"ord_123\"}",
    "delay": "30s"
  }'

The resources you create echo their mode back so you always know which side you’re on:

{
  "id": "sch_…",
  "object": "schedule",
  "mode": "test",
  "endpoint": "https://example.com/hooks/orders",
  "method": "POST",
  "state": "active"
}

Data is fully isolated per mode

Test and live are separate datasets within the same project. A sk_test_… key cannot read, list, or mutate live data, and a sk_live_… key cannot touch test data. Isolation is enforced at the query layer: every read and write is scoped by (project, mode).

This applies to everything keyed off a request:

• Schedules, endpoints, and deliveries are mode-scoped. GET /v1/schedules, GET /v1/deliveries/{id}, and attempt history return only rows for the calling key’s mode.
• Idempotency keys are mode-scoped too. The same idempotency_key used by a sk_test_… request and a sk_live_… request will not collide: they resolve to independent schedules. A test request never replays a live response, or vice versa.

Caution

There is no cross-mode read. If you create a schedule with a test key and then call the API with a live key, you’ll get a 404 for that schedule. It doesn’t exist in live data. Switching modes means switching keys, and you start from an empty, independent dataset.

Only live first attempts count toward the SLO

SchedStack publishes a 100–300 ms dispatch SLO (fired_at − scheduled_for, p99, where fired_at is the first byte out). The SLO measures dispatch initiation (when we start the send), not your receiver’s response time.

The published number is computed over a deliberately narrow population:

• live mode only: test-mode dispatches are excluded entirely.
• First attempts only (the initial fire). Retries, reclaim/recovery fires, rate-limit or breaker deferrals, catch-up/coalesced fires, and DST-shifted fires are all excluded.

Test mode is for correctness, not timing. Use it to verify that your endpoint receives, verifies the signature on, and idempotently handles a delivery, but don’t read anything into test-mode dispatch latency.

Develop safely in test mode

1. Build against a sk_test_… key. Point your integration at the same base URL and paths: only the key changes. Schedule short delays, watch deliveries land, and inspect retries and the dead-letter view without touching live data.

2. Verify the full contract. Confirm your endpoint verifies the Sched-Signature and dedupes on the delivery ID: at-least-once delivery means you own deduplication. Test mode is the place to prove this before real traffic.

3. Swap to sk_live_… to go live. Same code, live key. Because data is isolated, nothing you created in test leaks into live. You start clean. Keep the test key wired into CI and local dev.

Tip

Treat the two keys like any other environment secret: sk_test_… in development and CI, sk_live_… only in production. Keys are shown once at creation and stored hashed. If you lose one, mint a new one rather than trying to recover it.

Where to go next

• Idempotency: how idempotency keys are scoped and how to dedupe at-least-once delivery.
• Retries & dead-letter: what happens when a delivery doesn’t land on the first attempt.
• Quickstart: schedule your first durable delivery and watch it land.