OTLP delivery events — your stack, not ours

Blindrelay exports delivery metrics to your OTLP collector. You own retention, access control, and alerting — next to application metrics in Grafana, Datadog, or Honeycomb. No vendor message log required.

Why OTLP instead of a dashboard

Traditional ESPs retain every message so they can show a searchable log. That retention is the cost of the dashboard. Blindrelay inverts the model: relay the mail, emit signals, discard content. Your observability stack becomes the system of record for delivery — with the same RBAC, retention, and audit trail you already enforce for app data.

What you get

• Metrics — Counters for sent, delivered, hard bounce, soft bounce, and quota events — labeled by domain and API key id.
• Webhooks — HTTPS webhooks for teams without a collector: relay_accepted, delivered, soft_bounce, hard_bounce, failed, complaint. Signed, and retried for about a day when your endpoint is down.
• In-app counters only — The Blindrelay dashboard shows hourly integer aggregates — not a per-message log, not replay, not search.

Wire it up

Point your collector at the endpoint and headers shown on the Delivery settings page after sign-up. Typical labels include tenant_id, domain, api_key_id, and egress_key for shared vs dedicated IP sends.

Soft bounces end on our side — retry policy is yours. Issue a new POST /v1/send when your pipeline says to, with an optional Idempotency-Key header so HTTP retries do not duplicate mail.

Start with zero content retention

OTLP-first observability pairs with architecture that never stores message body or plaintext recipients. Read how that works on the zero-retention and security pages.

Sending from Gmail? See Gmail Send-as. Improving inbox placement? Read deliverability and pricing.