Delivery & reliability
Guaranteed delivery is a myth.
Accountability isn't.
Every webhook provider claims "guaranteed delivery." None of them can actually guarantee your endpoint will receive and process the event. Here's what honest SLAs look like.
What providers actually guarantee
Read the fine print. "Guaranteed delivery" usually means something very different from what you'd expect.
"We guarantee delivery"
They guarantee attempts. Your endpoint being down, misconfigured, or slow is on you.
"99.99% uptime SLA"
Their infrastructure uptime, not your delivery success rate. Two very different numbers.
"Exactly-once delivery"
Impossible to guarantee across network boundaries. At-least-once with idempotency is the honest answer.
"Never lose a webhook"
If they acknowledge it, maybe. But can they prove they acknowledged it? Can you?
At-least-once vs exactly-once
Exactly-once delivery
Impossible to guarantee
Across network boundaries, you cannot guarantee a message is delivered exactly once. The receiver might process it, crash before acknowledging, and receive it again. This is a distributed systems reality, not a product limitation.
At-least-once delivery
Achievable with trade-offs
You can guarantee the message is delivered at least once. Duplicates are possible. The solution is idempotency on the receiver side — and that's your responsibility.
Exactly-once processing
The honest goal
At-least-once delivery + idempotent receivers = exactly-once processing. Transyt provides deduplication at the gateway level and passes provider event IDs so you can enforce idempotency in your application.
What Transyt actually guarantees
We don't promise magic. We promise provable outcomes.
We guarantee storage
Every webhook is written to PostgreSQL before we return 200 OK. If we acknowledged it, it exists.
We guarantee attempts
10 delivery attempts with exponential backoff. If your endpoint is reachable, we'll reach it.
We guarantee evidence
Every attempt logged: timestamp, response code, error message. You'll know exactly what happened.
We guarantee replay
Failed deliveries can be replayed with one click. The data is never lost, even if delivery failed.
How to evaluate webhook SLAs
Questions to ask any webhook provider — including us.
What exactly is covered by your uptime SLA?
Is it their infrastructure uptime, or your delivery success rate? These are different metrics.
What happens when delivery fails?
How many retries? What's the backoff schedule? Is the payload preserved for replay?
Can you prove a webhook was received?
Not just delivered — received. Is the original payload stored before forwarding?
What evidence exists for auditors?
Timestamps, signatures, delivery attempts, response codes — all exportable?
What's the remediation path for missed events?
Can you replay? Can you export and reprocess? Or is the data just gone?
Why this matters for audits
During a SOC 2 audit or incident postmortem, "we guarantee delivery" means nothing. Auditors want evidence:
- Proof the event was received (timestamp, signature validation)
- Proof delivery was attempted (attempt log with timestamps)
- Proof of outcome (success response or failure details)
- Remediation path (replay capability, export for reprocessing)
A webhook provider that promises "guaranteed delivery" but can't produce this evidence is a liability, not an asset.
See how Transyt proves delivery without false guarantees
Honest SLAs. Complete evidence. Replay when things go wrong.
See how it works