CHARON GATE · WEBHOOK RELIABILITY
Catch failed webhooks before they become incidents.
Best for: Teams receiving inbound webhooks from payment, identity, or SaaS providers.
Events drop during deploys. Retries are inconsistent. Replay is manual and untracked.
Stable ingest URLs, fast acknowledgements, durable storage, exponential backoff, dead-letter queue, and manual replay — for the events your product depends on.
At-least-once delivery · tenant-isolated · honest semantics
Receive, retry, replay.
A narrow layer between providers and your application. Webhook insurance — for the path that carries your revenue.
Receive
Point your provider at a stable Charon URL. We acknowledge fast, persist the payload, and hand off to the background — your destination's latency never touches the critical path.
Retry
Exponential backoff with jitter. Transient 5xx and timeouts get another chance; clear 4xx fails fast.
Replay
When policy exhausts, the event lands in DLQ with full context. Fix the destination, replay — a new delivery chain tied to the original. No asking the provider to resend.
Visibility, retries, DLQ, replay.
The control plane focuses on operator clarity. Every ingress is a durable record; every forward is an explicit, timed, inspectable attempt.
Event stream
Headers, raw body, content type, and correlation IDs land in one place. Filter by endpoint or provider, trace an ID across retries without digging through logs.
Delivery attempts
No anonymous retries. Every POST to your app is an attempt row: latency, HTTP family, retryability, and a bounded response preview.
Failure triage
Dead-lettered events stay in an inbox, not in limbo. Triage by status family, endpoint, or provider — then fix, adjust policy, or replay.
Replay with lineage
Manual replay issues a new event and delivery chain while preserving ties to the original. Recover from bad deploys without re-wiring the provider.
Practical controls.
No theatre. What ships: cryptography, isolation, and honest delivery semantics.
HMAC verification
Stripe and GitHub adapters, plus generic HMAC where you bring the secret. Constant-time compares; timestamp windows where the format allows.
Encrypted secrets
Signing secrets and destination auth are encrypted at rest. Nothing sensitive is echoed back from the API.
Tenant isolation
Every query is tenant-scoped. DLQ, replays, and exports stay inside the workspace boundary.
At-least-once semantics
Duplicates can happen. Dedupe with provider IDs or Charon delivery headers — your handlers stay idempotent.
Common questions
Which providers does Charon Gate support out of the box?
Adapters for Stripe and GitHub HMAC ship by default, plus generic HMAC where you bring the secret. The ingest URL itself is provider-agnostic — anything that POSTs a webhook works (Clerk, Resend, Shopify, custom producers, internal services).
How does the retry policy work?
Exponential backoff with jitter. Retryability is decided per HTTP status family (5xx and selected 4xx retry; 2xx and most 4xx don't). The schedule is bounded so traffic spikes don't pile up indefinitely — anything that exceeds the schedule lands in the DLQ for inspection or manual replay.
What goes into the dead-letter queue?
Events whose delivery chain exhausted the retry budget, or which a downstream service explicitly rejected as non-retryable. DLQ rows keep the original headers, raw body, every attempt with its latency and response preview, and a correlation ID so you can trace the full lineage when you replay.
Is delivery exactly-once?
No — Charon Gate is at-least-once by design. Duplicates can happen (provider re-sends, network blips, replay). Your handlers stay idempotent and dedupe on the provider event ID or the Charon delivery header. We err on the side of "deliver again" rather than "drop silently".
How is the signing secret protected?
Signing secrets and destination auth are encrypted at rest. Nothing sensitive is echoed back from the API — masked values only. HMAC verification uses constant-time compares, and the supported providers also enforce a timestamp window.
How does Charon Gate compare with Blackglass?
Different problems. Blackglass is Linux operational integrity — SSH posture, fleet baselines, drift detection, audit exports. Charon Gate is webhook reliability — durable ingest, retries, DLQ, replay. Many teams run both.
Further reading: Why we built Charon Gate · A short webhook reliability primer.
Charon Gate is the connective tissue.
Charon Gate routes events between the other two products in the stack — making it possible to respond to infrastructure signals automatically, without manual intervention in the critical path.
Acheron Vault — event-driven backup verification
Acheron Vault verifies that your backups actually restore. Instead of relying on fixed cron schedules, Charon Gate lets you trigger an Acheron Vault verification run immediately after a database migration, a deployment pipeline, or any other infrastructure event that warrants a fresh recoverability check. If the verification fails, Charon Gate queues the alert and guarantees delivery to your team regardless of downstream availability.
Blackglass — alert routing and closed-loop response
When Blackglass classifies a high-severity drift finding on a Linux host, it fires a signed webhook to Charon Gate. Charon Gate delivers the alert to your team and simultaneously triggers Acheron Vault to run a backup health check on the affected target — so detection, alerting, and data safety verification all happen in a single automated chain.
POST /ingest/… → 202 Accepted → verify → forward → retry → DLQ → replay. Built for teams on Stripe, GitHub, Clerk, Resend, Shopify, and custom webhook producers.