HERE Core cache control

The fin.System.clearCache API combines multiple Electron session APIs (clearCache and clearCacheData) into a single call without exposing options for fine-grained control. This all-or-nothing behavior can cause unintended side effects, for example, clearing service workers alongside the HTTP cache can break offline-capable applications, even when the intent was only to refresh stale web content.

HERE Core 44 introduces fin.System.clearHTTPCache and fin.System.clearCacheData for more granular control of cached resources. These APIs let platform providers refresh stale content without breaking offline functionality or other applications' storage.

important

fin.System.clearCache remains available for backward compatibility, but platform providers on HERE Core 44+ should migrate to the new APIs to avoid unintentionally removing service workers and application storage.

• fin.System.clearHTTPCache: Clears only the HTTP response cache (HTML, CSS, JS, images). Does not touch service workers, Cache Storage, localStorage, or any other web storage API. Use this when you want to force-refresh stale network resources without affecting offline capabilities.

• fin.System.clearCacheData(options): Clears web storage APIs selectively. The dataTypes array controls which storage types are cleared, the origins array clears data for only the given origins, and the excludeOrigins array clears everything except for the given origins. clearCacheData does not clear the HTTP cache.

The table below summarizes what each API clears:

Data Type	clearHTTPCache	clearCacheData	clearCache (legacy)
HTTP Cache	Yes	No	Yes
Service Workers	No	Yes (via dataTypes)	Yes
Cache Storage	No	Yes (via dataTypes)	Yes
localStorage	No	Yes (via dataTypes)	Yes
Cookies	No	Yes (via dataTypes)	Yes
IndexedDB	No	Yes (via dataTypes)	Yes
Origin Scoping	N/A	Yes (via origins and excludeOrigins)	No

Why Migrate from clearCache?

Platform providers commonly call fin.System.clearCache on startup to ensure users receive the latest versions of hosted applications. However, because clearCache removes everything, including service worker registrations, cache storage entries, localStorage, and cookies, it can introduce the following problems:

• Offline mode breaks Service workers are removed, so applications cannot serve cached content when the network is unavailable.

• Cross-application impact Storage belonging to all hosted content applications is wiped, not just the target application.

• State loss User preferences, session data, and other client-side state stored in localStorage or IndexedDB are destroyed.

Migration Guide

Replace clearCache with clearHTTPCache

The simplest and most common migration. If your platform calls clearCache primarily to refresh stale web content, swap it directly:

Before

// Clears everything, breaks offline mode, removes all storage
await fin.System.clearCache();

After

// Clears only HTTP response cache, preserves service workers
await fin.System.clearHTTPCache();

Scope storage clearing by origins (if needed)

If your platform also needs to clear specific storage types, for example, to reset a misbehaving application's localStorage, use clearCacheData with origins or excludeOrigins scoping to avoid affecting other applications:

// Clear localStorage and IndexedDB for all applications except one
await fin.System.clearCacheData({
  dataTypes: ["localStorage", "indexeddb"],
  origins: ["https://example-1.com"],
});

Combine both APIs (full refresh without service worker loss)

If you previously relied on clearCache to wipe everything and want equivalent behavior while protecting service workers:

// Refresh HTTP cache
await fin.System.clearHTTPCache();

// Clear application-scoped storage without touching service workers
await fin.System.clearCacheData({
  dataTypes: ["cookies", "localStorage", "indexeddb", "cachestorage"],
  excludeOrigins: ["https://example-2.com", "https://example-3.com"],
});