Proyectos multi-tenant
Proyectos por usuario con Row-Level Security de Postgres. Crea tokens API por proyecto limitados a un solo tenant — las fugas nunca cruzan proyectos.
Self-hosted · Licencia MIT
Pasa el payload. Nosotros nos encargamos del resto.
Una alternativa ligera al ingress hospedado tipo QStash. Cola multi-tenant, entrega HTTP con reintentos, schedules cron y grupos de mensajes con orden estricto — todo sobre tu propio Postgres.
Hecho para colas de producción
Seis primitivas. Un Postgres. Cero dependencias hospedadas.
Tokens API por proyecto
Bearer pk_xxx:sk_yyy, hasheado con bcrypt en reposo. Mostrado una sola vez al crearlo, revocable al instante desde el dashboard.
Mensajes únicos
POST de un job HTTP: origin, path, method, headers, body, reintentos, opcional runAt o delaySeconds, opcional idempotencyKey.
Grupos de mensajes
Un origin + varios paths, ejecutados en orden estricto. Postgres impone el orden de hermanos al momento del claim — sobrevive a reinicios y a múltiples workers.
Schedules cron
Expresión cron + timezone por fila. Un tick central de dispatch encola los schedules vencidos; schedule_runs deduplica workers solapados.
Reintentos y backoff
Los intentos fallidos pasan a pending_retry con backoff. Tras max_retries: dead. Cada intento queda registrado en delivery_attempts.
Tres líneas de HTTP
Funciona con curl, con el SDK, o con cualquier cliente HTTP.
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
}'Casos de uso
Lo que de otro modo tendrías que construir tú.
Webhook fan-out
Toma un evento entrante y despáchalo a muchas URLs downstream, cada una con su propia política de reintentos. No pierdas ni una entrega por una API third-party inestable.
Workflows guiados por cron
Programa expresiones cron por fila. Un único tick central de dispatch dispara los vencidos — sin cron del SO por schedule, sin Vercel-cron por job.
Pipelines HTTP estrictamente ordenadas
¿Necesitas que el paso 2 espere al paso 1? Los grupos de mensajes garantizan el orden a nivel de base de datos — incluso entre múltiples dispatchers.
Self-host o usa la edición hospedada
El mismo motor, dos formas de ejecutarlo.
| Característica | Hospedada | Self-host |
|---|---|---|
| Infraestructura | Corre en api.passthatpayload.com — cero ops para ti. | Un contenedor + Postgres en tu servidor. Runbook de Hetzner en el README. |
| Propiedad de los datos | Guardados en nuestro Postgres compartido, aislados por proyecto vía RLS. | Tu base de datos, tus backups, tu retención. |
| Cuotas | Tier gratuito generoso durante la beta. | Sin cuotas — solo limitado por tu Postgres y tu ancho de banda. |
| Soporte | Comunidad + best-effort. | Comunidad + issues en GitHub. |
Precios
Gratis durante la beta. Self-host gratis para siempre.
Free
$0/mes
Para todos los que usan la edición hospedada durante la beta.
- Proyectos ilimitados
- Todos los endpoints API
- Soporte de la comunidad
Self-host
$0para siempre
Ejecuta Pass That Payload en tu propio servidor.
- Código fuente completo (MIT)
- Runbook de Hetzner incluido
- Sin límites de uso
Pro
—próximamente
Cuotas más altas, SLA, soporte prioritario.
- Cuotas más altas
- SLA + soporte prioritario
- Exportación de audit logs
Preguntas frecuentes
¿En qué se diferencia de QStash?
QStash está muy bien pero es solo hospedado. Pass That Payload ofrece las mismas primitivas — encolado HTTP, reintentos, schedules — pero self-hostable sobre un solo Postgres + contenedor Node, con proyectos multi-tenant y RLS de fábrica.
¿Funciona con localhost o URLs privadas?
Sí, cuando el dispatcher corre en Node (worker o runtime nodejs). El dispatcher hace el fetch a la URL destino él mismo, así que todo lo accesible desde su red funciona.
¿Qué pasa cuando se agotan los reintentos?
El mensaje pasa al estado "dead" tras max_retries fallos. Dentro de un grupo de mensajes, el siguiente hermano sigue ejecutándose — un fallo no cancela el resto de la cadena.
¿Cómo se garantiza el orden entre varios workers?
El orden se impone en Postgres al momento del claim: la siguiente fila de un grupo no se toma hasta que los hermanos anteriores hayan salido de pending, pending_retry o processing. Todos los dispatchers respetan la misma regla.
¿Qué regiones están disponibles?
La edición hospedada corre en Hetzner Falkenstein (Alemania, UE). Self-host donde puedas ejecutar Node + Postgres 16.
¿Es open source?
Sí — licencia MIT en GitHub. Mira el repositorio Console para el código fuente, el paquete SDK y el runbook del operador.