Webhookery v0.2.0-pilot

Webhookery v0.2.0-pilot Release Notes

Status: pilot prerelease for controlled, single-region, self-hosted
evaluation.

Date: 2026-06-08

This release packages the v0.2.0 Pilot Readiness Checklist as a tagged pilot
prerelease. It advances Webhookery from a broad release-candidate foundation
toward an evaluator-ready webhook evidence gateway: incident packets, governed
replay, forensic event search, live-provider proof guides, release artifacts,
and public repository trust metadata are now first-class.

It does not claim broad production readiness, provider certification,
compliance certification, exactly-once delivery, provider-side event
completeness, external timestamping, or legal evidentiary certification.

Target Pilot Story

A payment or integration webhook failed. Webhookery shows what arrived, whether
the provider signature was valid, which route matched, which delivery attempts
happened, why delivery failed, who replayed it, what changed, and which
verifiable evidence remains.

Notable Changes Since v0.1.0-rc1

• Incident reports with API, CLI, persistence, OpenAPI, and local demo evidence
  support.
• Versioned evidence bundle manifests and an offline bundle viewer.
• Forensic event search, stable event timeline output, and stable API problem
  codes.
• Replay reason codes, replay approval expiry, and replay approval policies.
• Raw payload access reason capture and elevated audit behavior.
• SSRF hardening for copied HTTP clients by disabling unintended redirect
  behavior.
• Pilot doctor checks, local failure-drill tooling, restore-drill contract
  checks, and richer release-candidate evidence paths.
• Stripe, GitHub, and Shopify live-provider proof guides with redacted public
  samples and freshness metadata.
• GitHub-native public metadata: README badges, CodeQL, OpenSSF Scorecard,
  Dependabot, issue and PR templates, CODEOWNERS, Code of Conduct, GitHub
  Pages, and generated OpenAPI/reference docs.
• Release asset publication for installable archives, checksums, OpenAPI and
  migration hashes, manifest, provenance metadata, SBOM carry-through, and
  release evidence.

Release Evidence

The canonical evidence template remains docs/release-evidence-template.md.

For this pilot prerelease, public release evidence should include:

• tag and source commit from GitHub Releases
• make docs-check output
• make release-acceptance output
• make rc-check output
• make finalize output
• provider conformance and provider proof metadata output
• coverage gate output and coverage.out
• DB-backed make rc-check output from the release workflow PostgreSQL service
• performance smoke output
• Docker image digest
• source and image SBOMs
• Trivy HIGH/CRITICAL image scan result
• release archives, SHA256SUMS, manifest, and provenance metadata
• branch protection or repository ruleset status
• external review status or accepted-risk record

The GitHub release workflow generates release artifacts with local
fake-provider/fake-receiver evidence, DB-backed release-candidate checks, SBOMs,
image digest, Trivy scan result, and non-claim language. It does not perform
live Stripe, GitHub, Shopify, Slack, AWS, Vault, or customer receiver calls.

Accepted Pilot Risks

These items are accepted only for the v0.2.0-pilot prerelease and block
broader production-maturity language:

Risk	Status	Mitigation
master branch protection is not enabled and no repository ruleset is configured.	accepted for pilot prerelease	Public CI/security/release workflows are required for release evidence; CODEOWNERS exists for review routing; branch protection must be enabled before broader production positioning.
External security or production-readiness review is not completed.	accepted for pilot prerelease	Public docs keep release as controlled self-hosted pilot evidence; external review remains required before using broader production-readiness language.

The current accepted-risk registry is docs/external-review-accepted-risks.md.

Upgrade And Rollback Notes

• Read docs/stability.md before relying on API, CLI, migration, or support
  windows.
• Apply migrations only after backing up the database.
• Migrations 026 through 029 add incident and replay governance state.
• Rollback across applied migrations may require restoring from backup; do not
  assume automatic down-migration safety for production data.
• Run docs/operations.md restore drills before promoting a deployment that
  changes persistence or evidence storage behavior.

Known Limitations

• v0.2 pilot readiness remains single-region and self-hosted.
• PostgreSQL remains the evidence authority for accepted events.
• Redis, Kafka, NATS, object storage, and external queues are not evidence
  authorities.
• Live-provider proof guides are manual and sanitized; they are not provider
  certification.
• Provider reconciliation cannot prove provider-side event completeness.
• Replay is at-least-once and can create duplicate downstream side effects.
• Raw payload access remains elevated and audited.
• Customer-controlled receiver URLs remain hostile input and must pass SSRF
  validation at configuration and delivery time.
• Commercial support, license exceptions, and production-readiness reviews
  require separate written scope.

Non-Claims

Webhookery v0.2.0-pilot does not claim:

• exactly-once delivery
• provider-side event completeness
• downstream business success
• compliance certification
• external timestamping
• legal evidence certification
• hosted-service availability
• provider certification
• multi-region active-active operation

Validation Commands

Run these from a clean checkout before publishing or promoting the pilot
prerelease:

make docs-check
make release-acceptance
make rc-check
make finalize

For DB-backed release-candidate checks:

WEBHOOKERY_TEST_DATABASE_URL=postgres://... make rc-check

For provider proof metadata:

make provider-conformance-check
make provider-proof-check
go run ./cmd/whcp doctor pilot --no-network

Live-provider proof guides are manual and external. Do not run them in CI, do
not commit completed live evidence bundles, and do not include provider
secrets, raw payload bodies, raw signatures, customer data, or production
database URLs in public artifacts.

Webhookery v0.1.0-rc1

Webhookery v0.1.0-rc1 Release Notes

Status: release candidate for controlled, single-region, self-hosted
evaluation.

Date: 2026-05-27

This release packages Webhookery as self-hosted webhook evidence infrastructure:
durable capture before inbound success, provider-aware verification, signed
delivery, replay, reconciliation evidence, retention, audit-chain verification,
and operator-facing release evidence.

Who This Release Is For

Use this release candidate if you need to evaluate whether Webhookery can help
with webhook evidence, debugging, replay, and self-hosted operational review.
It is most relevant for platform, SRE, security, and integration teams that need
to prove what happened to webhook events.

Do not treat this release candidate as a managed service, compliance
certification, or provider completeness guarantee.

Implemented Core Behavior

• Durable inbound capture before returning success.
• Raw body and header evidence preservation.
• Provider signature verification and local conformance vectors.
• Tenant-scoped sources, endpoints, routes, subscriptions, events, deliveries,
  attempts, replay, DLQ, quarantine, retention, audit, and export APIs.
• Signed outbound delivery with retry, DLQ, replay, and payload evidence.
• Versioned configuration evidence for reproducible route, retry, adapter,
  transformation, and replay decisions.
• Audit hash-chain verification and release evidence export foundations.
• Provider reconciliation and gap evidence where provider APIs and credentials
  permit it.
• Redacted production doctor, performance smoke, provider conformance checks,
  backup/restore scripts, deployment profiles, and observability examples.

Release Evidence

The canonical evidence template is docs/release-evidence-template.md.

For this release candidate, release evidence should include:

• commit SHA and tag
• make release-acceptance output
• make rc-check output
• DB-backed make rc-check output when WEBHOOKERY_TEST_DATABASE_URL is
  available
• provider conformance output
• performance smoke output
• Docker image digest
• source and image SBOMs
• Trivy HIGH/CRITICAL image scan result
• branch protection or repository ruleset status
• external review status or accepted-risk record

The GitHub release workflow generates a release evidence artifact with SBOMs,
image digest, local fake-provider/fake-receiver evidence, and non-claim
language. It does not perform live Stripe, GitHub, Shopify, Slack, AWS, Vault,
or customer receiver calls.

Upgrade And Rollback Notes

• Read docs/stability.md before relying on API, CLI, migration, or support
  windows.
• Run migrations only against a backed-up database.
• Run the restore drill from docs/operations.md before promoting a deployment
  that changes persistence or evidence storage behavior.
• Rollback across applied migrations may require restoring from backup; do not
  assume automatic down-migration safety for production data.

Known Limitations

• Single-region self-hosted operation is the supported release-candidate
  posture.
• Operators own PostgreSQL durability, object storage durability, backups,
  network policy, TLS, alert routing, and incident response.
• Provider reconciliation cannot prove provider-side event completeness.
• Local release acceptance uses fake/local providers and receivers only.
• Performance smoke output is a local sizing signal, not an SLA.
• Commercial support and license exceptions require a separate written
  agreement.

Non-Claims

Webhookery v0.1.0-rc1 does not claim:

• exactly-once delivery
• provider-side event completeness
• downstream business success
• compliance certification
• external timestamping
• legal evidence certification
• hosted-service availability
• multi-region active-active operation

Commercial Evaluation

Commercial license exceptions and paid evaluation packages are described in
COMMERCIAL.md. The commercial path does not change the technical non-claims
above unless a written agreement explicitly narrows scope for a specific
engagement.

Validation Commands

Run these from a clean checkout:

make docs-check
make release-acceptance
make rc-check
make finalize

For DB-backed release-candidate checks:

WEBHOOKERY_TEST_DATABASE_URL=postgres://... make rc-check