Keep the provider identity with the event
Persist the provider, account or tenant, event identifier, event type and referenced message identifier. Scope the duplicate key to the documented uniqueness boundary. Two providers can use different identifiers for the same conversation, and two status events can concern one outbound message.
Retain the original event time and the time your service accepted it. Those timestamps help distinguish delayed delivery from slow internal processing.
Acknowledge only after you can recover
Follow the provider’s verification and response requirements. Before returning a successful acknowledgment, make the accepted work durable enough to survive a process restart. Let a separate worker perform slower model or application work where that fits your architecture.
Use a durable uniqueness constraint or equivalent coordination around the action record. An in-memory set disappears on restart and is not shared by every running instance. The exact implementation depends on your storage and queue.
Exercise the unpleasant sequence
Replay one approved test event, restart the worker after acceptance, and deliver a status update later than expected. Confirm that the application creates one intended response and retains enough evidence to explain the outcome.
A deduplicated event does not by itself make a remote send exactly once. Also investigate the provider’s send-idempotency or lookup facilities and define how your application handles an uncertain send result.