---
schema_version: "1"
id: 8c4b4ff635ffc432c7774b7707f5158fa90824fb44700f0d51c9f17cdf965bb4
title: Event Message Durability
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/event-bus/pub-sub-api/guides/event-message-durability.md
canonical_url: https://developer.salesforce.com/docs/platform/pub-sub-api/guide/event-message-durability.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 3ade3140a493c89cb286d5163a7ea4c2fb1021cc55df5377360d7205c861bce6
products:
  - Pub/Sub API
  - Event Bus Docs
---
# Event Message Durability

Salesforce stores platform events and change data capture events for 72 hours. Using Pub/Sub API, you can retrieve events that are within the retention window. Retrieving stored events is helpful after the client disconnects and wants to catch up on missed events.

**note:** After the retention period, events are purged from the event bus. The purging process sometimes starts later, and as a result, platform events and change data capture events that are older than 72 hours can still be available. Salesforce doesn’t guarantee the storage of events beyond the retention period of 72 hours.

## Event Replay ID Field

Each received event message is assigned an opaque ID contained in the Replay ID field, represented as `ConsumerEvent.replay_id` in the protocol specification. The Replay ID field value, which is populated by the system when the event is delivered to subscribers, refers to the position of the event in the event stream. Replay ID values aren’t guaranteed to be contiguous for consecutive events. A subscriber can store a replay ID value and use it on resubscription to retrieve events that are within the retention window. For example, a subscriber can retrieve missed events after a connection failure. Subscribers must not compute new Replay IDs based on a stored Replay ID to refer to other events in the stream.

The `replay_id` field value isn’t guaranteed to be unique when Salesforce maintenance activities occur, such as an org migration. To uniquely identify a platform event message, use the event `id` field. When publishing an event, the field is `ProducerEvent.id`. For more information, see [Identify an Event with ProducerEvent.id and PublishResponse.correlationKey](/docs/platform/pub-sub-api/references/methods/publishstream-rpc.html#identify-an-event-with-producereventid-and-publishresponsecorrelationkey). For a received platform event message, use the `ConsumerEvent.event.id` field. The `id` field is present on platform events and not on change events.

## Retrieving Stored Events

To catch up on missed events during client shutdown, you can retrieve events that are temporarily stored in the event bus. By using the [Subscribe RPC Method](/docs/platform/pub-sub-api/references/methods/subscribe-rpc.html) with a `replay_preset` option, a subscriber can choose which events to receive, such as all events starting after a particular Replay ID. To do so, the client stores the Replay ID of the last processed event.

This high-level diagram shows how event consumers can read a stream of events by using various replay options.

![Replay stored events](https://developer.salesforce.com/docs/media/pubsub-replaying-events.png '{ "title": "Replay stored events"}')

Instead of managing the Replay ID on the client with the `Subscribe` RPC method, you can use the [ManagedSubscribe RPC Method (Beta)](/docs/platform/pub-sub-api/references/methods/managedsubscribe-rpc.html) to more easily track the events received. With `ManagedSubscribe`, you commit the Replay ID of the last processed event on the server. You don’t worry about managing a replay ID store on the client. Then when resubscribing, the subscription resumes after the stored Replay ID.

On rare occasions, the stream of retained events can be reset if the Salesforce org is moved to a new instance. As a result, you can no longer access the retained events. See [Salesforce Maintenance Activities and Sandbox Refresh](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_api_considerations.htm#maintenance_activities) in the _Platform Events Developer Guide_.

**See Also**

- [_GitHub_: Pub/Sub API proto file](https://github.com/forcedotcom/pub-sub-api/blob/main/pubsub_api.proto)