Skip to content
Observability

“Delivered” is a summary. We keep the sentence.

Acceptance is not delivery, and a percentage cannot tell you which one you got. Every event OutSend records keeps the receiving provider's own response, so a person or an agent can explain what happened instead of guessing.

Start sendingEvents reference
Observability

Every event, every payload, queryable.

Event types, raw provider payloads, queryable logs, signed webhooks, and delivery logs — everything you need to explain what happened.

Eight event types, one schema

Delivery, bounce, delivery delay, complaint, open, click, reject, and rendering failure. Normalised so you can handle them uniformly — never at the cost of the original.

  • The provider's own words, kept · Every event stores the raw payload it came from. When a message is deferred you see the actual SMTP response and the host that said it, not our summary of it.

A log you can actually query

Filter by event type, recipient, and date range. Open any message to see its full lifecycle in order, with timestamps down to the millisecond.

  • Retention that is not a trick · 30 days to 12 months by plan, configurable on Dedicated. Retention is a trust feature, so we are deliberately generous with it rather than using it as a lever.

Signed webhooks

Six events pushed to your endpoint as they happen, each signed with an HMAC secret unique to that endpoint. Verify over the raw body before you parse anything.

  • Webhook delivery logs · Attempts, response codes, and response bodies are recorded per delivery. When your endpoint is the thing that broke, that is visible too.
Webhook payload

The useful half is the provider object.

We normalise events into one schema so your handler stays simple. We never throw away what the provider actually said, because that is the part that tells you whether this is an addressing problem or a reputation problem.

  • Concentrated deferrals at a single provider almost always mean the latter, and the response text usually says so outright.
webhook deliverySigned
POST /your-endpoint
X-OutSend-Signature: sha256=8c1f…              # HMAC of the raw body
Content-Type: application/json

{
  "event":      "email.bounced",
  "occurred_at": "2026-09-13T09:14:22Z",
  "email_id":   10482,
  "recipient":  "person@example.com",
  "bounce_type": "Transient",
  "provider": {
    "response": "450 4.7.1 Not accepted, try again later",
    "reporting_mta": "mx.example-provider.com"
  }
}
What you can inspect

Go and check.

Documentation

  • The raw provider payload behind any event, exactly as it arrived.
  • A message's full lifecycle in order, with millisecond timestamps.
  • Every webhook delivery attempt, its response code, and its body.
  • Which events fired and which did not, and why.
  • Events reference
  • Webhooks
  • API reference

A deferral followed by a delivery is completely normal, and invisible on a platform that only reports a final percentage.

Read a trace that went wrong.Observability

The rest of the platform

Read a trace that went wrong.

A deferral followed by a delivery is completely normal, and invisible on a platform that only reports a final percentage.

Start sendingOr self-host it

Open core · never venture-backed · operated by Martin Business Consultants