Inspiration

Debugging webhooks was frustrating: failed requests were hard to reproduce, delivery history was often incomplete, and local development required extra tools just to receive an event. We built trusin to make every webhook traceable and actionable.

What it does

trusin receives webhooks, persists events, routes them to destinations, retries failed deliveries, and shows a complete delivery timeline. Developers can inspect payloads, response status, latency, retry attempts, and failures from one dashboard.

How we built it

We built the backend, queue workers, and CLI in Rust; the dashboard uses React and Vite. PostgreSQL stores organizations, events, rules, and delivery attempts. Redis powers queues and scheduled retries. trusin also includes a terminal UI and MCP server for AI-assisted operations.

Challenges we ran into

Reliable retries without duplicate deliveries, secure outbound destination validation, multi-tenant authentication, OAuth, rate limiting, and making local development work without forcing every developer to use a separate tunnel.

Accomplishments that we're proud of

  • Durable webhook delivery with retry timelines.
  • Provider-to-hook routing for HTTP, Slack, and Telegram destinations.
  • Dashboard, CLI/TUI, and MCP integration from one shared API.
  • Secure authentication with Google, GitHub, Turnstile, API tokens, and scoped permissions.
  • Open-source and self-hostable infrastructure.

What we learned

Webhook infrastructure is more than forwarding HTTP requests. Observability, idempotency, queueing, retries, security, and developer experience all need to work together for developers to trust delivery data.

What's next for trusin - Webhook Relay

We are improving team workflows, destination integrations, delivery analytics, local-first development, and AI-assisted debugging. The goal remains the same: make it easy to answer, “What happened to this webhook?” in seconds.

Built With

Share this project:

Updates