Control How Long Responses Are Cached
On This Page
You can now customize how long your API responses are cached in Corsfix. Previously, the cache duration was fixed. Now, you can set any duration that fits your use case.
Updated Cache Header
Caching still uses the same x-corsfix-cache header, but instead of just setting it to true, you now pass a duration value.
Here’s what it looks like:
fetch("https://proxy.corsfix.com/?https://api.example.com/data", { headers: { "x-corsfix-cache": "10m", // cache for 10 minutes },});The value follows a simple format: a number followed by a unit.
| Format | Description | Example |
|---|---|---|
<number>s | Seconds | 30s (30 seconds) |
<number>m | Minutes | 10m (10 minutes) |
<number>h | Hours | 2h (2 hours) |
<number>d | Days | 1d (1 day) |
If no unit is specified (e.g. 10), it defaults to seconds.
Defaults and Limits
The maximum cache duration is 1 day (1d). Anything above that gets capped at 1 day.
If the value can’t be parsed or you’re still using the old true value, it defaults to 1 hour, so existing setups won’t break.
Why Use Caching?
Caching is useful beyond just performance. With Corsfix, cached responses:
- Don’t count towards your throughput capacity. This lets you effectively handle more traffic with the same resources.
- Are served from a global edge CDN, which means lower latency for your users regardless of their location.
- Reduce load on the target server, so you’re not hitting the same endpoint repeatedly for the same data.
For APIs that don’t change frequently, like public datasets, configuration endpoints, or reference data, setting a longer cache duration makes a lot of sense.
Conclusion
You can now cache your CORS proxy responses with any duration up to 1 day, giving you full control over the trade-off between freshness and performance.
For full details on the cache header and its behavior, check out the Cached Response documentation.