Engineering guides / Angular applications and AWS infrastructure
By Arte Soft engineering · 24 October 2026
Webhook idempotency: make duplicate delivery harmless
A webhook provider may deliver the same notification more than once, deliver events out of order or retry after your response is lost. A receiver must handle those conditions without granting duplicate credits or applying stale state. Idempotency is therefore part of the business operation, not simply a checkbox added to the HTTP endpoint.
Understand the provider contract
Read how the provider identifies events, signs requests, retries delivery and represents state changes. Verify authenticity using the documented mechanism before trusting the payload. Preserve the fields needed to determine whether a notification has already been processed, while limiting retained personal data. Distinguish an event identifier from a transaction identifier: several legitimate events can refer to the same underlying purchase. Decide which state transitions are valid and whether a later event can supersede an earlier one. Without that model, a duplicate check can accidentally discard useful updates or accept an old notification as current truth.
Make the state change durable
Acknowledge receipt according to the provider’s expectations, but do not pretend that an in-memory flag makes processing safe. Store enough durable state to coordinate retries and concurrent workers. Where possible, combine the business write and processing marker within a consistent operation. Handle the uncertain interval between a completed external effect and a lost response. If a task is queued, distinguish received, processing, completed and failed work. A narrowly scoped ledger can make replay safe; a sprawling event platform is not always necessary. Choose machinery proportionate to the consequence of applying the operation twice.
Exercise the awkward sequences
Send the identical event twice, deliver two related events out of order and interrupt processing after the business write. Retry a failed event after the dependency recovers. Acceptance should show that the final balance or entitlement is correct and that legitimate changes are not blocked by the duplicate rule. Deliver a receiver contract, verification logic, state model and replay instructions. Keep a reconciliation route when provider state can be queried independently. An HTTP success response is not sufficient evidence: the important result is a consistent business record after the full sequence of delivery and failure conditions.
Keep test event fixtures free of reusable secrets and unnecessary customer content. A useful replay package should reproduce the ordering and state transitions while preserving the provider-specific verification requirements in the controlled test environment where they are evaluated.
Give operators a safe recovery tool
A failed notification should have a visible status and an identifiable reason without exposing secrets. Define who may replay it and which checks protect that action. Arte Soft’s own subscription-supported products make purchase-event handling a relevant engineering subject, not a claim that every provider behaves like Apple. Bring the provider documentation, example signed events and the action your backend performs. A scoped implementation can protect one valuable operation first. The tradeoff is a little additional persistence and testing in exchange for avoiding expensive manual corrections when ordinary retry behavior reaches production.
A provider-neutral ordering example
Consider an order-management webhook arriving twice while a customer record has not yet synchronised to the CRM. Record the delivery identity, validate the provider signature, and make the order mutation durable before marking it processed. An authorised replay should repair a failed CRM update without creating another order. This guide concerns general asynchronous integration; Apple subscription notification types and credit-entitlement rules are a separate lifecycle described in the App Store server-notifications guide.
Relevant Arte Soft work
GPT Realtime Assistant — our own product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.
Sources and further reading
Need help with Reliable webhook implementation?
Send the current app, system or brief, the behaviour you need and your constraints. We can agree a discovery, implementation or repair scope with concrete acceptance criteria.
Discuss this with Arte Soft