Multi-tenant projects
Per-user projects with Postgres Row-Level Security. Mint per-project API tokens scoped to a single tenant — leaks never cross projects.
Self-hosted · MIT licensed
Pass the payload. We'll handle the rest.
A lean alternative to hosted QStash-style ingress. Multi-tenant queue, HTTP delivery with retries, cron schedules, and strictly-ordered message groups — all running on your own Postgres.
Built for production queues
Six primitives. One Postgres. Zero hosted dependencies.
Per-project API tokens
Bearer pk_xxx:sk_yyy, bcrypt-hashed at rest. Shown once on creation, revocable instantly from the dashboard.
Single messages
POST one HTTP job: origin, path, method, headers, body, retries, optional runAt or delaySeconds, optional idempotencyKey.
Message groups
One origin + many paths, executed strictly in order. Postgres enforces sibling ordering at claim time — survives restarts and multiple workers.
Cron schedules
Per-row cron expression + timezone. One central dispatch tick enqueues due schedules; schedule_runs dedupes overlapping workers.
Retries & backoff
Failed attempts move to pending_retry with backoff. After max_retries: dead. Every attempt is logged in delivery_attempts.
Three lines of HTTP
Drop in curl, the SDK, or any HTTP client.
curl -X POST https://api.passthatpayload.com/api/v1/messages \
-H "Authorization: Bearer pk_xxx:sk_yyy" \
-H "Content-Type: application/json" \
-d '{
"origin": "https://api.example.com",
"path": "/hooks/order-created",
"body": { "orderId": 42 },
"maxRetries": 5
}'Use cases
What you'd otherwise build yourself.
Webhook fan-out
Take one incoming event and dispatch it to many downstream URLs, each with its own retry policy. Don't lose a single delivery to a flaky third-party API.
Cron-driven workflows
Schedule cron expressions per row. One central dispatch tick fires the due ones — no OS cron per schedule, no Vercel-cron-per-job.
Strictly-ordered HTTP pipelines
Need step 2 to wait for step 1? Message groups guarantee order at the database level — even across multiple dispatchers.
Self-host or use the hosted edition
Same engine, two ways to run it.
| Feature | Hosted | Self-host |
|---|---|---|
| Infrastructure | Runs on api.passthatpayload.com — zero ops on your side. | One container + Postgres on your own server. Hetzner runbook in the README. |
| Data ownership | Stored in our shared Postgres, isolated per project via RLS. | Your database, your backups, your retention. |
| Quotas | Generous free tier during beta. | No quotas — limited only by your Postgres + bandwidth. |
| Support | Community + best-effort. | Community + GitHub issues. |
Pricing
Free during beta. Self-host is free forever.
Free
$0/month
For everyone using the hosted edition during beta.
- Unlimited projects
- All API endpoints
- Community support
Self-host
$0forever
Run Pass That Payload on your own server.
- Full source code (MIT)
- Hetzner runbook included
- No usage limits
Pro
—coming soon
Higher quotas, SLA, priority support.
- Higher quotas
- SLA + priority support
- Audit logs export
Frequently asked
How is this different from QStash?
QStash is great but hosted-only. Pass That Payload is the same primitives — HTTP enqueue, retries, schedules — but self-hostable on a single Postgres + Node container, with multi-tenant projects and RLS built in.
Does it work with localhost / private URLs?
Yes, when the dispatcher runs in Node (worker or nodejs route runtime). The dispatcher fetches the target URL itself, so anything reachable from its network works.
What happens when retries are exhausted?
The message transitions to status "dead" after max_retries failures. Inside a message group, the next sibling still runs — a single failure does not cancel the rest of the chain.
How is order guaranteed across multiple workers?
Ordering is enforced in Postgres at claim time: the next row in a group is not picked until earlier siblings have left pending, pending_retry, or processing. Multiple dispatchers all honor the same rule.
What regions are available?
The hosted edition runs in Hetzner Falkenstein (Germany, EU). Self-host wherever you can run Node + Postgres 16.
Is it open source?
Yes — MIT licensed on GitHub. See the Console repository for the source, the SDK package, and the operator runbook.