> For the complete documentation index, see [llms.txt](https://docs.jentis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jentis.com/key-features/data-retention.md).

# Data Retention

Premium Feature

Data Retention ensures your event data is never lost during downstream endpoint outages or temporary network disruptions. When a destination service becomes unavailable or returns server-side errors, JENTIS automatically captures and caches incoming event packets in a secure buffer.

Once the connection to the destination is safely re-established, the system automatically replays the cached packets in the order they were received, ensuring complete data delivery to your analytics and marketing stack.

### How It Works

1. **Automatic Detection:** The system continuously monitors response codes and connection stability for all configured vendor destinations.
2. **Packet Caching:** If a vendor endpoint drops connection, times out, or returns retryable HTTP status codes (e.g., `500`, `502`, `503`, `504`, or rate-limit `429`), incoming event packets are routed to our isolated storage layer.
3. **Queue & Replay:** As soon as the vendor endpoint passes health checks, the buffered event packets are replayed sequentially to restore real-time parity.

### Important Consideration: Vendor Timestamp Handling

Replaying cached data may cause temporal inconsistencies in your downstream reports, depending on how specific vendor APIs handle incoming event timestamps:

* Event-Time Processing (Recommended): Vendors that ingest and respect the original event timestamp (e.g., standard Google Analytics 4 Measurement Protocol events sent with a `time_offset` or explicit event timestamp) will correctly place replayed data into its original historical context.
* Received-Time Processing: Vendors that ignore event timestamps and stamp incoming data upon arrival will register replayed packets at the time of delivery rather than the time of user action.

{% hint style="info" %}
**Impact on Reporting:** If a vendor processes data using *received-time*, an outage replayed hours later may result in an artificial spike in activity at the time of replay, alongside a corresponding dip during the original outage window.
{% endhint %}

### Best Practices

* Check your downstream vendors' API documentation to confirm whether they support custom timestamp parameters during server-to-server ingestion.
* When evaluating attribution or performance reports immediately following a known vendor outage, allow time for replayed queues to clear before running analytical queries.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.jentis.com/key-features/data-retention.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.