Examples

This appendix links to every YAML example in this directory, grouped by concern. Core YAML files are complete configurations checked by hookway validate. replay.yaml files configure the optional replay service; docker-compose.yaml files start the local demonstrations. Runtime configs stay beside their Compose examples under this directory. File headers explain each demonstration; showcase/invalid-* files intentionally fail validation.

Starting configurations

Shared connections and reliable ingestion

Destination reference configs

Each file showcases one destination type with all available options documented via comments.

MCP gateways

See the MCP gateway guide for deployment and OAuth setup. Gateway caller authentication is separate from outbound API credentials.

Auth strategy reference configs

Each file demonstrates one auth type with the exact fields required by that type.

Ingress adapters

These use neutral resource names and explicit admission. For the complete field contracts and deployment boundaries, see Ingress adapters.

Builder / showcase fixtures (showcase/)

These are the configs the web builder round-trips. make validate-examples skips invalid-*.

Sentry notifications

• sentry-discord.yaml: selected Sentry issue alerts to Discord, with signature verification, duplicate protection and async delivery.
• Setup and signed local fixture.

Templates (examples/templates/)

Each file is a runnable configuration and a template in the builder palette. Notification templates insert the format-and-POST pair. Stripe/Paddle/Sentry ingest templates insert the verified prefix; connect its envelope to your destination. The XML template inserts a complete XML pipeline.

Every template file is a production-shaped config: secrets live in the environment (secret_ref with rotation overlap, webhook URLs as ${ENV}), inbound traffic is authenticated (never no_auth), /metrics is on a private port behind security.api_key, and envelopes only forward allowlisted headers.

Running validation

# Validate the default config
make validate

# Validate all example files (`hookway validate`, no server)
make validate-examples

# Boot every valid example, GET /healthz, and POST a signed request to each flow
make test-examples

make test-examples boots configs with test publishers and loopback HTTP; it does not contact your production destinations. invalid-* files are intentional validation failures. When adding an example directory, add it to validate-examples in the Makefile so CI checks it.

Persistent production-style local stack (production-local/)

Use production-local/docker-compose.yaml with make prod-local-bootstrap (PROD_LOCAL_MODE=full adds replay and its console; PROD_LOCAL_PROTECTION=1 selects Redis protection). Bootstrap generates private credentials and copies ordinary YAML once, preserving later operator edits. The supported workflow uses Make and Compose directly, with no test helper. Ordinary shutdown preserves named volumes; explicit reset requires the selected project name. Browser ports bind to loopback, while internal APIs and stores stay on the Compose network. See Local development for validation, operating commands, URLs and architecture limits.

This runs the same application with local HTTP and private destinations.

Disposable dev stack (make dev-up)

docs/development/local-development.md walks through sending a webhook, taking notify-sink down, and retrying what it missed.

Replay service, two replicas each (replay/)

The dev and replay Compose stacks build a separate console frontend using web/Dockerfile. The dev console is at http://localhost:8082, with the public builder at /builder; its API URL is http://localhost:8081. In the replicated replay example the browser connects to the API replica at http://localhost:8090. For balanced API traffic, supply an independently deployed browser-reachable API load balancer URL through REPLAY_API_URL. Set REPLAY_CONSOLE_ORIGIN to the frontend's exact origin. Console replicas and replay replicas scale independently; fixed local port mappings are a convenience for this demo, not an autoscaling front door. Production ALB/TLS/WAF configuration is deployer-owned.

Provider ingress contracts

See the compatibility matrix for local test evidence, consumer deduplication, recovery requirements and unsupported modes.

Shared rate limits and duplicate protection

Set the referenced environment variables, choose the backend used by each node, and migrate PostgreSQL before serving. Both declared stores are checked at startup, so remove unused stores. See Protection stores.

Multi-YAML configuration

One YAML per flow keeps central settings in multi-yaml/core.yaml and references separate orders and billing flow bodies. Single-file configuration remains supported.

• MCP event subscriptions: PostgreSQL-backed subscriptions, authenticated issue webhooks, and signed callbacks.
• Signed HTTPS callback receiver: standard-library test receiver using your TLS certificate.

More in this section

• Shared destination