Architecture Center
Durable integration and receipts
Show how an external event is validated, processed through a session, gated by a decision, and executed as an idempotent outbound effect with a signed receipt.
previewreferenceContract >=0.8 <1.0Reviewed 2026-07-20
Problem statement
Integrations must survive retries, partial failures, and duplicate deliveries without double-applying effects. Idempotency keys and receipts make durable execution safe.
When to use
- You receive external events and must act on them reliably.
- Outbound effects must not double-apply on retry.
- You need retry and dead-letter handling with an auditable record.
When not to use
- Fire-and-forget notifications with no correctness requirement.
- Synchronous request/response with no external side effect.
Flow
Inbound webhookValidated eventSession commandWorker processingDecision gateOutbound effectSigned receiptRetry or dead-letter
Resource inventory
- Webhook + validation
- Authenticates and validates the inbound event.
- Session + worker
- Processes the event as governed work.
- Command + effect
- The gated outbound operation and its result.
- Receipt
- Durable record keyed by idempotency key.
Failure modes
- Effect failed (retryable)
- Retry with the same idempotency key; applies at most once.
- Effect failed (permanent)
- Route to dead-letter; inspect the receipt and correct the cause.
- Duplicate delivery
- Idempotency key returns the original receipt, no second effect.
Security controls
- Inbound webhook signature validation.
- Idempotency keys on all outbound commands.
- Effect destinations allowlisted per environment.
- Receipts and audit events on every attempt.
Deployment checklist
- Webhook secret configured and rotated.
- Idempotency-key strategy defined per operation.
- Retry and dead-letter policy set.
- Receipt and audit monitoring in place.
Related quickstart: Inspect a receipt →