feat: Webhooks support

[xernobyl]

Adds Standard Webhooks support for Hub events, based on River as a queue.

Event / Webhooks pipeline (architecture)

1. API request – Client calls a mutation (e.g. POST /v1/feedback-records, DELETE /v1/webhooks/{id}). The handler calls the corresponding service.
2. Service publishes event – The service persists the change, then calls MessagePublisherManager with event type and payload (e.g. PublishEvent(FeedbackRecordCreated, record)). This is fire-and-forget into an in-memory channel; the API does not wait for webhook delivery.
3. MessagePublisherManager fans out – A background goroutine reads from the channel and calls PublishEvent on each registered provider (today: only WebhookProvider). Per-event timeout is configurable via MESSAGE_PUBLISHER_PER_EVENT_TIMEOUT_SECONDS (default 10s) so one provider doesn’t block others. If the channel is full, the event is dropped and a warning is logged. Channel buffer size is configurable via MESSAGE_PUBLISHER_BUFFER_SIZE (default 1024).
4. WebhookProvider enqueues jobs – For each event, it queries the DB for enabled webhooks that subscribe to that event type, builds a batch of job params (capped by WEBHOOK_MAX_FAN_OUT_PER_EVENT, default 500), and calls River’s InsertMany once. No HTTP here; only list + enqueue. Jobs are unique by (event id, webhook id) for 24 hours.
5. River runs the worker – River picks up jobs and runs WebhookDispatchWorker for each. The worker loads the webhook by ID, builds the payload, and calls WebhookSender.
6. WebhookSender delivers – Signs the payload (Standard Webhooks), sets headers (webhook-id, webhook-signature, webhook-timestamp), POSTs to the webhook URL. 2xx → job complete. 410 Gone → webhook disabled in DB, no retry. Other failures → retry with backoff until max attempts; after last failure the webhook can be disabled.

In short: API → Service → MessagePublisherManager (channel) → WebhookProvider (DB + River InsertMany) → River queue → WebhookDispatchWorker → WebhookSender → HTTP POST. The slow/unreliable part (HTTP to third-party URLs) stays in the worker and sender; the API stays non-blocking.

What’s in this branch

Webhooks

• CRUD API for webhook endpoints: POST/GET/PATCH/DELETE /v1/webhooks, with list/filter support.
• Event types: feedback_record.created, feedback_record.updated, feedback_record.deleted (and webhook lifecycle events).
• Delivery: River-backed worker sends signed payloads (Standard Webhooks) to subscriber URLs with retries and configurable concurrency/attempts.
• Batch enqueue: Provider uses River’s InsertMany (one call per event) and a configurable fan-out cap per event (WEBHOOK_MAX_FAN_OUT_PER_EVENT, default 500) to avoid blocking the publisher when an event has many webhooks.
• Migrations: 002_webhooks.sql, 003_webhook_disabled_state.sql (and dependency on goose migrations).
• OpenAPI: New webhook schemas and operations in openapi.yaml.

Infrastructure & config

• River: River client and WebhookDispatchWorker in cmd/api/main.go; webhook provider enqueues jobs via InsertMany (one batch per event, capped by WEBHOOK_MAX_FAN_OUT_PER_EVENT).
• Docker Compose: riverui service for the River UI (port 8081), with basic auth via RIVER_BASIC_AUTH_USER / RIVER_BASIC_AUTH_PASS (no defaults in compose).
• Config: WEBHOOK_DELIVERY_MAX_CONCURRENT, WEBHOOK_DELIVERY_MAX_ATTEMPTS, WEBHOOK_MAX_FAN_OUT_PER_EVENT; MESSAGE_PUBLISHER_BUFFER_SIZE, MESSAGE_PUBLISHER_PER_EVENT_TIMEOUT_SECONDS, SHUTDOWN_TIMEOUT_SECONDS; .env.example updated with River UI auth and the above vars.

Other

• Message publisher: Event publishing abstraction used by the feedback-records service to trigger webhook delivery; buffer size and per-event timeout configurable.
• Integration tests: Webhook CRUD and auth covered in tests/integration_test.go.

How to try it

1. make init-db and make river-migrate.
2. docker compose up -d for Postgres + River UI (set River UI auth in .env).
3. Create a webhook (e.g. feedback_record.created) and create a feedback record; confirm delivery in River UI and at the webhook URL.

[BhagyaAmarasinghe]

.

[BhagyaAmarasinghe]

Thanks for the PR :)
I have added several comments that needs to be looked.

[BhagyaAmarasinghe]

Thank you, LGTM 🚀