Purging

Purging effectively removes an object from the Fastly cache, prompting future requests that would otherwise hit that cached object to proceed to origin as a cache miss.

In practice, while some types of purge do effectively delete content, others will mark the content as stale, allowing you to refresh caches more gracefully if desired. This kind of purge is called a soft purge (see soft vs. hard purge below).

Purging can also be accomplished using the web interface; see our guides to single purges, wildcard purges, surrogate key purges, and soft purges.

Endpoints

Purge a URL

PURGE*

Purge everything from a service

POST/service/service_id/purge_all

Purge by surrogate key tag

POST/service/service_id/purge/key

Purge multiple surrogate key tags (header)

POST/service/service_id/purge

Purge multiple surrogate key tags (JSON)

POST/service/service_id/purge

Soft vs. hard purge

By default, purging an object will make it immediately inaccessible to new requests. The data might not be removed from storage right away, but it will no longer be matched by any cache lookup and will eventually be evicted. This is a 'hard' purge.

For improved performance and to protect backend servers from being overloaded by an inrush of traffic following a purge, you can perform a 'soft' purge, which marks the affected object as stale rather than making it inaccessible. The presence of stale objects can reduce backend load by allowing for conditional revalidation and other performance-enhancing patterns. To learn more, read about using and revalidating stale content.

Single object, surrogate key, and bulk surrogate key purges all support soft purge. To make a purge soft, add the following HTTP request header when making the API request:

Fastly-Soft-Purge: 1

Purge-all requests cannot be done in soft mode and will always immediately invalidate all cached content associated with the service. To do a soft-purge-all, consider applying a constant surrogate key tag (e.g., "all") to all objects.