Satellites

Satellites are companion tools that orbit the core — they use Sparrow, they never reach inside it. Every satellite talks to the same public REST API and signed-webhook contract you do, so the delivery pipeline (matching, retries, signing, audit trail) stays one small, boring server. Delete every satellite and Sparrow still works; add your own and it is a first-class citizen.

The satellites

Satellite	What it does	Direction
CLI	Push events, tail deliveries, receive webhooks locally, apply recipes, debug templates — the terminal loop	both
Recipes	Adapters as config: one YAML file turns deliveries into Slack, Discord, ntfy, PagerDuty, or ClickHouse payloads — rendered server-side, nothing extra runs	out
Sources	Cron schedules plus webhook receivers that verify the provider’s signature and re-publish as typed Sparrow events — see the Sources page for the current provider list	in
Sinks	A signed-delivery receiver that forwards out of HTTP land: SMTP email, S3/MinIO archives, and OTLP log export	out

Each page explains the satellite’s technical path — exactly which API calls it makes, how signatures are verified, and what happens per delivery.

Real-World Architecture & Use Cases

Satellites allow you to orchestrate end-to-end event flows across cloud providers, SaaS vendors, databases, and notification channels without writing glue microservices.

Scenario 1: E-Commerce Payment & Order Fulfillment Pipeline

When a customer purchases an item on your web store:

1. Source (sparrow-sources): Listens to incoming Stripe webhooks (payment_intent.succeeded), validates Stripe’s signature, and re-publishes a clean stripe.payment_intent.succeeded event to Sparrow.
2. Core (Sparrow): Deduplicates the event using the idempotency key, matches subscriptions, and signs outbound requests with HMAC-SHA256 / Ed25519.
3. Recipe (slack): Instantly renders a Block Kit card to #sales-notifications showing order totals and customer metadata.
4. Sink (sparrow-sinks / S3): Streams raw delivery payloads to an Amazon S3 bucket (s3://acme-audit-logs/events/2026/03/17/) for long-term financial audit compliance.

Scenario 2: Developer Operations & Infrastructure Alerting

When an automated deployment job or infrastructure monitor detects a failure:

1. Source (sparrow-sources / Cron): Fires a health.check tick every 60 seconds to evaluate upstream service status.
2. CLI (sparrow push): CI/CD pipelines in GitHub Actions push deployment failure events (deploy.failed) directly to Sparrow.
3. Recipe (pagerduty): Formats and triggers a high-severity incident in PagerDuty using the stable event_id as the deduplication key to prevent alert noise during retries.
4. Sink (sparrow-sinks / OTLP): Forwards delivery execution traces and logs to an OpenTelemetry Collector for Grafana / Datadog dashboards.

The contract

Anything you build against the same three rules inherits the whole pipeline:

1. Public API only — no database access, no server internals.
2. Verify signatures — check the Standard Webhooks headers before trusting a delivery.
3. Fail loudly, stay stateless — return non-2xx and let Sparrow’s retries do the work.

Note

Sparrow blocks private-network delivery URLs by default (SSRF guard). For any local receiver — sparrow listen, a dev sink, a laptop endpoint — start the server with SPARROW_ALLOW_PRIVATE_NETWORKS=true.