> 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/developer-guide/consent-javascript-sdk/reprocessing-in-the-consent-javascript-sdk.md).

# Reprocessing in the Consent JavaScript SDK

The **Consent JavaScript SDK** includes a powerful feature called **reprocessing**.\
This allows JENTIS to **re-evaluate and re-trigger tracking commands** whenever consent information is updated—without requiring a full page reload.

Reprocessing ensures that any previously triggered commands are executed (or withheld) according to the **latest consent state** for a given vendor.

### How Reprocessing Works

* Reprocessing occurs **only when the page scope remains the same**.
* If the page is reloaded, the JavaScript scope is reset, and all tracking starts fresh.
* All **JENTIS States**—such as `track:event`, `track:submit`, or any other custom state, are stored temporarily.
* When consent for a tool (vendor) changes, these stored commands are reprocessed to match the new consent decision.

**Example:**\
If a user initially denies consent for Analytics, but later accepts it, previously triggered events (e.g., a `track:pageview`) can be reprocessed so they are now sent to Analytics.

### Special Case: Single Page Applications (SPAs)

For SPAs (e.g., React, Vue, Angular), navigation within the app also **resets reprocessing**.\
This means:

* Even if an event is still available in memory, JENTIS clears its internal cache on navigation.
* JENTIS treats SPA navigations and regular page reloads the same—**no reprocessing occurs** unless explicitly configured otherwise.

### Controlling Reprocessing Reset

You can control whether **navigation resets the reprocessing cache**:

```javascript
// Disable reprocessing reset (keep events across SPA navigations)
window.jentisApp.reprocessingCache_deactivate_reset();

// Enable reprocessing reset (default behavior)
window.jentisApp.reprocessingCache_activate_reset();
```

### Default Behavior

* By default, **reprocessing reset is active** → SPA navigations clear the cache.
* To keep reprocessing active across navigations, call `reprocessingCache_deactivate_reset()` **before JENTIS initializes**.

### When to Call the Reset Functions

**Timing is critical**:

* In **JENTIS**: Use the trigger **Before JENTIS Bundle Load**.
* In your **own application**: Call the function together with the JTM container code snippet.

✅ **Tip:** Use reprocessing strategically to ensure users’ updated consent choices apply instantly without losing valuable tracking data.

## What if consent reprocessing is not working?

### Issue: `history.replaceState` Executed After JENTIS Tracking

Some websites are configured to update or push the current URL to the browser's history stack late in the page lifecycle. When this occurs, the `history.replaceState` function runs *after* tracking has already been executed.

Under these conditions, the JENTIS Event Cache resets automatically. From a legal and compliance perspective, cached tracking events cannot be carried over or attributed to a newly updated page state.

**How to Resolve This Issue**

Choose one of the following approaches:

* Execute Earlier: Adjust your website’s code to execute `history.replaceState` as early as possible in the DOM execution order (prior to JENTIS initialization).
* Disable Reprocessing Logic: Deactivate the JENTIS cache-resetting logic so events are retained, following the configuration steps outlined in the documentation above.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.jentis.com/developer-guide/consent-javascript-sdk/reprocessing-in-the-consent-javascript-sdk.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.