The Headless Application Update Configuration screen manages the requests and settings sent to and applied on the headless (Next.js) application. The fields below describe every option on the page, including their purpose, defaults, and valid ranges.
Primary settings
| Field | Description |
|---|---|
| Edge Secret | The secret used for signing edge requests between Spark and the headless application. Use the eye icon to reveal the value, the copy icon to copy it, and Generate New to create a new secret. Important: after generating a new secret you must update your head application with the new SPARK_REGENERATION_SECRET value for Spark to remain functional. See How to install the NPM module |
| Delete On Revalidate | When checked, stale cache entries are deleted before revalidation. Default: enabled (checked). Only relevant for JSS and Content SDK pages router applications. |
| Route Handler Type | The Next.js routing model used by the edge application. Options: App Router or Pages Router. Default: App Router. Note: App Router apps will also require changing the Site Path Prefix setting for each applicable site, see Understanding site configuration |
| Revalidate Mode | Controls how revalidation targets are resolved for App Router integrations. Options: byPath will use item paths, or byTag will send item IDs. Default: byPath. (Only shown when Route Handler Type is set to App Router.) |
Advanced configuration
These options should normally be left as their default values, but can be altered to work around performance and rate-limiting bottlenecks that can occur in some edge applications, for example, for SitecoreAI, too many regeneration requests too close together could trigger rate-limiting on the Experience Edge API
| Field | Description | Default | Valid range |
|---|---|---|---|
| Pages per payload request | How many pages are allowed per payload request sent to a single endpoint. | 50 (XM), 10 (XMC) | 1 - 1000 |
| Update requests per publish to a single endpoint | How many requests are sent to each headless application per publish. Therefore, total pages regenerated will be: Pages per payload request x Update requests per publish Pages in excess of this total will have their cache cleared without regeneration. |
50 (XM), 10 (XMC) | 1 - 1000 |
| Regeneration update timeout per request (seconds) | The timeout applied to each request sent to the headless endpoint per update. | 10 | 1 - 90 |
| Regeneration update failed retry attempts | The number of retries attempted per update per endpoint. | 3 | 0 - 6 |
| Regeneration update interval between requests (milliseconds) | The time between requests sent to the headless endpoints. This affects both retries and chunked regeneration requests. | 1000 | 500 - 10000 |
| Regeneration Processing Delay (seconds) | The delay applied before regeneration processing starts. | 20 (XM) 0 (XMC) |
0 - 300 |
| Regeneration update failure retry HTTP statuses | The HTTP statuses returned from the headless application that will cause the request to be retried. Enter as comma-separated 3-digit status codes (e.g. 408, 500, 504) - 408 (request timeout), 500 (server error), 504 (gateway timeout). | 408, 500, 504 | Comma-separated 3-digit codes |
| Allow parallel regeneration updates? | Allows the headless endpoints to be updated in parallel. This linearly increases concurrent regeneration requests based on the number of endpoints configured, and can therefore increase the chance of hitting rate limits or putting source systems under too much load. | Enabled (checked) |
Actions
- Save Configuration - Saves the current settings.
- Cancel - Discards changes and returns to the environment.