CLASSIFIED: OPEN DOSSIER
Webhook Configuration
2026-05-09 Innora Engineering
# Webhook Configuration
Use this landing page to decide which webhook path fits the integration. Innora currently separates customer workflow webhook reviews, website newsletter delivery, and GitHub repository automation so each path keeps a clear owner, validation boundary, and failure mode.
## Webhook Integration Map
| Path | Owner | Auth boundary | Failure behavior |
|------|-------|---------------|------------------|
| Customer workflow webhook review | Product and solutions engineering | Reviewed through `/contact?ref=webhooks` before external systems are connected | No production connector is promised until the review is complete |
| Newsletter subscription webhook | Website operations | HTTPS `NEWSLETTER_WEBHOOK_URL` with optional bearer token forwarding | Returns `NEWSLETTER_NOT_CONFIGURED`, provider error, or timeout instead of fake success |
| GitHub repository webhook | Engineering operations | `x-hub-signature-256` HMAC checked with `GITHUB_WEBHOOK_SECRET` | Missing signature returns 401, invalid signature returns 403, missing server secret returns 500 |
## Customer Workflow Webhooks
Use `/contact?ref=webhooks` when the webhook will trigger a security workflow, external notification, CI/CD step, or downstream business system. The review should capture trigger source, payload shape, approval boundary, retry policy, and rollback or human-review requirements before implementation begins.
## Newsletter Webhook Delivery
The website newsletter route accepts validated email submissions at `/api/subscribe`. It only forwards to a configured HTTPS webhook endpoint, optionally adds a server-side bearer token, and reports provider failure or timeout explicitly. This route is for website operations, not for general customer automation.
## GitHub Repository Webhook
The repository webhook endpoint is `/api/github/webhook`. GitHub must send `x-hub-signature-256`, and the server must have `GITHUB_WEBHOOK_SECRET` configured. Ping events return a lightweight confirmation; push events are handed to the repository automation service after signature verification.
## Implementation Checklist
1. Identify the webhook owner and whether it is customer-facing, website operations, or engineering operations.
2. Define the trigger source, payload schema, retry behavior, and maximum acceptable side effect.
3. Confirm the auth boundary: Turnstile, HTTPS webhook token, HMAC signature, or manual review.
4. Decide the failure response that operators and callers should see.
5. Link the implementation back to `/docs/api` endpoint taxonomy and `/developers/examples` before launch.