webhook-debugger

KO | EN

gitlite — search

#hacktoberfest #react #llm #go #golang #machine-learning #deep-learning #docker #nodejs #java #windows #vue #security #openai

webhook-debugger

(★ 40)

Request logging and webhook debugging SaaS — inspect, replay, and monitor HTTP webhooks in real-time. Built with Next.js, TypeScript, Supabase, Cloudflare

webhook-debugger Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# webhook-debugger

Request logging and webhook debugging SaaS — inspect, replay, and monitor HTTP webhooks in real-time. Built with Next.js, TypeScript, Supabase, Cloudflare Workers, and deployed on Vercel.

## Phase 1 (this build)

Core logging MVP: magic-link auth, endpoint creation, logs retrieval, and a dashboard UI.

**In scope:** Next.js app, Supabase schema + RLS, magic-link auth flow, endpoint + logs APIs, dashboard.
**Out of scope (later phases):** Cloudflare Worker receiver (Phase 2), Creem billing (Phase 2), replay/star/search (Phase 3).

## Stack

Next.js 14 (App Router) · TypeScript · React 18 · Supabase (Postgres + RLS) · Tailwind · jose (JWT) · Zod

## Getting started

```bash
# 1. Install dependencies
npm install

# 2. Configure environment
cp .env.example .env.local   # then fill in your Supabase keys + a JWT_SECRET

# 3. Apply the database schema
#    Paste supabase/migrations/0001_init.sql into the Supabase SQL editor and run it,
#    or use the Supabase CLI: supabase db push

# 4. Run the dev server
npm run dev                  # http://localhost:3000
```

### Environment variables (`.env.local`)

| Variable | Purpose |
| --- | --- |
| `NEXT_PUBLIC_SUPABASE_URL` | Supabase project URL |
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | Supabase anon key (client) |
| `SUPABASE_SERVICE_ROLE_KEY` | Supabase service-role key (server routes only) |
| `NEXT_PUBLIC_APP_URL` | Base URL used to build endpoint URLs |
| `JWT_SECRET` | Secret used to sign/verify session JWTs |

## Auth flow (Phase 1)

Email service isn't wired up yet, so magic-link tokens are returned directly by the API for testing:

1. `POST /api/auth/send-magic-link` with `{ email }` → creates a single-use token (returned in the response and stored in `magic_link_tokens`).
2. On `/auth/confirm`, submit the email + token → `POST /api/auth/confirm-magic-link` verifies it, creates the user + free subscription on first sign-in, and returns a 7-day session JWT.
3. The JWT is stored in `localStorage` and sent as `Authorization: Bearer <token>` to protected APIs.

Phase 2 replaces the returned token with a real emailed magic link (Resend/SendGrid).

## API routes

| Method | Route | Description |
| --- | --- | --- |
| `POST` | `/api/auth/send-magic-link` | Issue a magic-link token |
| `POST` | `/api/auth/confirm-magic-link` | Verify token, return session JWT |
| `POST` | `/api/webhooks/create` | Create an endpoint |
| `GET` | `/api/webhooks/list` | List the user's endpoints (with request counts) |
| `DELETE` | `/api/webhooks/delete?id=<uuid>` | Soft-delete an endpoint |
| `GET` | `/api/logs/[endpoint_id]` | Paginated logs for an endpoint |

## Project structure

```
app/                 # App Router pages + API routes
components/           # Dashboard / Auth / Common UI
lib/                  # supabase, auth (JWT), api client, types, utils
supabase/migrations/ # SQL schema + RLS policies
```

## Notes

- API routes use the Supabase service-role key (bypasses RLS) and scope every query by `user_id` in application code. RLS policies are still enabled as defence-in-depth for any future anon-key access.
- All inputs are validated with Zod; all responses are JSON.

webhook-debugger

webhook-debugger Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

webhook-debugger

webhook-debugger Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README