Fast Purge API v3
Purge content from your edge servers by URL, ARL, content provider (CP) code, or cache tag.
Learn more:
Download this API’s RAML and JSON schema descriptors.
Overview
The Fast Purge API provides a programmatic interface for you to purge edge content. In this version, purge your own set of URLs or ARLs (Akamai resource locators), or any content grouped under a cache tag or content provider (CP) code. Delivery products such as Ion, Adaptive Media Delivery, Dynamic Delivery, and Dynamic Site Accelerator all support Fast Purge. If you’re using a legacy Content Control Utility (CCU) API to purge content, see the migration instructions to convert your API programs to use Fast Purge. To purge streaming or media content, use the Media Services API.
If you’re a developer, website architect, or content administrator, you can also use the Akamai Control Center interface to purge content. For details on how to get started with the Fast Purge interface, see the documentation.
For more information about Fast Purge, see Fast Purge API concepts.
Who should use this API
The Fast Purge API is a simple API that enables purging content at the edge. It allows developers and architects to purge a set of URLs or ARLs, or any content grouped under a cache tag or CP code within approximately five seconds.
The API also comes with a CLI version that you can set up as a task within automation tools such as CircleCI or Jenkins.
For more information on content control using TTL (Time to Live) methods, refer to Time to Live (TTL) in Cache: Methods and Considerations.
Get started
To configure this API for the first time:
Review Get Started with APIs for details on how to set up client tokens to access any Akamai API. These tokens appear as custom hostnames that look like this:
https://akzz-XXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX.luna.akamaiapis.net
.To enable this API, choose the API service named CCU APIs, and set the access level to READ-WRITE.
Review Identity and Access Management for details on how to create your API access credentials and authorizations. When creating, adding, and naming clients for API access, do so under CCU APIs, not General APIs. Note that you can select all CP codes when configuring your API credentials. This means all current and future CP codes on the current contract, not all CP codes on the account.
Get help from the Akamai developer community and provide feedback. You can also contact your Akamai representative for support. Akamai wants to hear from you!
Fast Purge API concepts
This section describes the conceptual objects you deal with when interacting with this API, and provides pointers to where you can learn more.
Fast Purge. The Fast Purge utility (formerly known as Content Control Utility or CCU) completes purge requests within approximately five seconds. Fast Purge supports requests to invalidate or delete a set of URLs or ARLs, or any content grouped under a cache tag or CP code on Akamai
staging
andproduction
networks. In general, use invalidate, as it causes the edge server to treat content as though its TTL has expired. Use delete for compliance or copyright-related purge requests, as it completely removes all content from servers.NOTE The
network
parameter is optional but if omitted, it defaults toproduction
. When provided, it must be eitherproduction
orstaging
.invalidation. Content invalidation, or refresh request, is the default purge action in most cases. An invalidation purge action causes Akamai edge servers to send an
If-Modified-Since
(IMS) request to the origin on subsequent requests for invalidated content. If the timestamp of the object at the origin is more recent than the one in cache, the latter replaces the new object from the origin. Otherwise, it’s re-validated for the duration of the TTL. If an object doesn’t have aLast-Modified
header, a regular GET request is sent to origin.NOTE: To avoid serving stale content, ensure the
Last-Modified-Timestamp
(LMT) value on the origin server is updated to a newer timestamp than the LMT value of the current object.deletion. This purge action removes the object from cache so it’s no longer available to clients. Deleting content results in an expensive GET request to the origin server, and prevents Akamai from serving this content stale if the origin server is down.
Akamai resource locator (ARL). A string that represents an object in cache such as a cache key. For example,
/L/16382/123456/15m/www.example.com/myfile.jpg
. The ARL is similar to the URL but the ARL is specifically defined for objects served using the Akamai edge network. You can specify an ARL to purge specific versions of an object that you can’t purge using just the URL. To get the cache key for any URL, pass in aPragma: akamai-x-get-cache-key
request header for theX-Cache-Key
response header.Cache tag. A label, such as a surrogate key or content tag, that you assign to content from the origin. To deploy a set of cache tags, add a single
Edge-Cache-Tag
header to your origin content. Use commas to separate case-sensitive cache tag values. Once a set of objects have been cached with a tag, they can be purged together with a single Fast Purge API call. You can apply many tags to any object, allowing you to purge by any overlapping set of classifications you define, such asblack-friday
,flash-sale
,electronics
,laptops
,tablets
. If an object matches any one of the tags in a purge request, then its cache is refreshed.Content provider (CP) code. Identifies a set, typically a subset, of content on your origin server. CP codes also provide additional granularity in reports and to track billing. Each contract supports at least one CP code. You cannot apply the same CP code to content under more than one contract. If you’re using Property Manager, use the Property Manager API (PAPI) to get a list of CP codes available for a selected contract and group. PAPI also allows you to generate new CP codes, assign them to properties, and apply them within property rules.
Cache tag constraints and other considerations
When deploying tagged content, apply a single Edge-Cache-Tag
response header, otherwise only the first one works. Header values
are comma-delimited, with optional whitespace, and limited to 128
bytes. Each tag value, derived from the ABNF token
format, may not
feature interior whitespace or any of the following punctuation
characters: *"(),:;<=>?@\[]{}
. This example shows how you might
overlap tag categories:
Edge-Cache-Tag: casual, knits, fall-sale
Ordinarily, your end users never receive the Edge-Cache-Tag
header.
You can use Property Manager’s Cache Tag Visibility behavior to
override that for any segment of your content, either always, or on
demand. Learn more.
If you use Drupal for content management, the Akamai Drupal 8 module can help you tag content. For information on effective ways to use cache tags to purge content, see best practices.
Logically, consider cache tags as part of the tagged content. Thus, new or changed tags need to be returned with a 200 response from the origin. A 304 response doesn’t update the cache tags. To make sure that tags are assigned to all targeted objects on the Akamai network, wait until they refresh based on their TTL value, or explicitly purge them when adding or changing tags.
Sample code
For sample code that demonstrates how to use this API, see the api-kickstart repository. Sample code is available in Python, Node.js, PHP, Ruby, and Perl. It’s frequently updated with new examples for Akamai APIs.
Rate limiting
This API uses rate controls to limit the number of purge requests that clients within a single account can make for a given time. It also limits the rate of URLs, CP codes, or cache tags that can be submitted. When rate limits are applied, the requests from all clients within the same account are counted together. For the purpose of rate limiting, ARLs are counted as URLs.
This table shows the enforced rate limits for API requests in general and for each type of object. An individual API request can include many URLs, CP codes, or cache tags.
Limit Type | Sustained Rate | Burst |
---|---|---|
API request | 50 requests per second | 100 requests |
URL/ARL | 200 URLs/ARLs per second | 10,000 URLs/ARLs |
CP code | 30 CP codes per minute | 300 CP codes |
Cache tag | 500 cache tags per minute | 5,000 cache tags |
The rate limiting algorithm used for sustained rate and burst follows a token bucket model.
There’s one bucket for requests and a separate bucket for each object type (URLs/ARLs, CP codes, and cache tags). The burst value in the table represents how many tokens the bucket can hold. The buckets start full of tokens. Tokens are constantly added to the bucket based on the sustained rate. Once the bucket is full, no more tokens can be added.
When an API request is made, the request may contain either URLs/ARLs, CP codes, or cache tags. First, the API request bucket is checked for tokens. If a token is available, one token is removed from the bucket. Next, the object type bucket is checked for tokens. The object type bucket needs to contain enough tokens to satisfy all of the objects in the request. If there are enough tokens, they’re removed from the bucket and the request is accepted. If there aren’t enough tokens in the object bucket, no tokens are removed, the API request token is returned to the API request bucket, and the entire request is denied.
For example, the token bucket for cache tags holds 5,000 tokens and refills at a rate of 500 tokens per minute. You can submit a burst of 5,000 cache tags if the token bucket is full, but this completely empties the token bucket. Cache tag tokens are refilled at 500 tokens per minute, so after one minute, the bucket has 500 tokens in it and another request with up to 500 objects can be processed.
You can submit a burst of 5,000 tags every 10 minutes, 1,000 cache tags every 2 minutes, or 500 cache tags every minute. In all cases, the average sustained rate is still 500 cache tags per minute. If you submit a burst of 5,000 cache tags followed immediately by another request for 500 cache tags, the second request for 500 cache tags is denied because there aren’t enough tokens left.
To purge more objects while remaining within defined limits, combine many objects into a single API request and reduce the rate of requests. A single API request may contain many objects of the same type, as long as the request body is smaller than 50,000 bytes.
Rate limit headers
When a request is denied due to rate limiting, the API responds with a 429
error, along with various X-Ratelimit-*
HTTP headers and rateLimit*
JSON members in the response body.
This table shows the rate limiting response headers returned by the API. These headers appear for both success and failure responses.
Rate Header | Description |
---|---|
X-Ratelimit-Limit-Per-Second |
The sustained rate limit for API requests per second. |
X-Ratelimit-Limit |
The burst limit for API requests. |
X-Ratelimit-Remaining |
Number of API requests remaining before the rate limit is exceeded. |
X-Ratelimit-Limit-Per-Second-Objects |
The sustained rate limit for objects per second. This value depends on the purge type being requested: URL/ARL, CP code, or cache tag. |
X-Ratelimit-Limit-Objects |
The burst limit for objects. This value depends on the purge type being requested: URL/ARL, CP code, or cache tag. |
X-Ratelimit-Remaining-Objects |
Number of objects remaining before the rate limit is exceeded. This value depends on the purge type being requested: URL/ARL, CP code, or cache tag. |
Rate limit response body
Rate limit headers are present in success and failure responses, while the rate limit response body members are only present in responses that are denied due to rate limiting.
This table shows the rate limiting response body JSON members for a 429 failure response.
Response Body JSON Member | Description |
---|---|
title |
Identifies the type of rate limit exceeded. The value is Rate Limit exceeded for API requests. For objects, the value can be URL Rate Limit exceeded (same for ARL), CPCODE Rate Limit exceeded , or TAG Rate Limit exceeded . |
rateLimit |
The burst limit for the limit type that was exceeded. |
rateLimitRemaining |
The number of API requests remaining before the rate limit is exceeded. |
rateLimitCurrentRequestSize |
The number of items in the request that exceeded this limit. |
Rate limit response examples
These examples show 429 failure responses when a URL purge request has exceeded an API request rate limit and an object rate limit.
In this first 429 failure response, the Rate Limit exceeded
title
in the response body shows that the API request rate limit was exceeded.
The X-Ratelimit-Remaining
header value is 0
and the rateLimitRemaining
response member is 0
. This means that there were no additional API requests
remaining at this moment, and the request was denied.
To stay within the rate limits, you can reduce the API request rate and use
the remaining 9904
URL objects, shown in the X-Ratelimit-Remaining-Objects
response header, in each purge request. This allows for a comparable purge
rate without exceeding the rate limit.
HTTP/1.1 429 Too Many Requests
Date: Tue, 12 Mar 2019 21:14:01 GMT
Content-Length: 239
Content-Type: application/api-problem+json
X-Ratelimit-Remaining: 0
X-Ratelimit-Limit-Per-Second: 50.00
X-Ratelimit-Limit: 100
X-Ratelimit-Remaining-Objects: 9904
X-Ratelimit-Limit-Per-Second-Objects: 200.00
X-Ratelimit-Limit-Objects: 10000
{
"supportId": "17PY1552425241133633-211776704",
"title": "Rate Limit exceeded",
"httpStatus": 429,
"describedBy": "https://developer.akamai.com/api/core_features/fast_purge/v3.html#httpcodes",
"rateLimit": 100,
"rateLimitCurrentRequestSize": 1,
"rateLimitRemaining": 0
}
In this next 429 failure response, the URL Rate Limit exceeded
title in
the response body shows that an object URL rate limit was exceeded. Note
that the object rate limit for a URL purge request is 200
URLs per second,
as shown in the X-Ratelimit-Limit-Per-Second-Objects
header. The
rateLimitRemaining
response member is 94
, which was the number of URLs
available to purge at that moment. When the purge request was submitted, it
contained 110
URLs, as shown in the rateLimitCurrentRequestSize
response
member. Because the request was 16 URLs over the current limit of 94
, it
was denied.
To maximize the purge rate without waiting, you can truncate the request to
contain 94
URLs, then resubmit it immediately. Alternatively, wait until
you can purge all 110
URLs at once, which in this case would only take
80 milliseconds.
HTTP/1.1 429 Too Many Requests
Date: Tue, 12 Mar 2019 21:14:31 GMT
Content-Length: 251
Content-Type: application/api-problem+json
X-Ratelimit-Remaining: 40
X-Ratelimit-Limit-Per-Second: 50.00
X-Ratelimit-Limit: 100
X-Ratelimit-Remaining-Objects: 94
X-Ratelimit-Limit-Per-Second-Objects: 200.00
X-Ratelimit-Limit-Objects: 10000
{
"supportId": "17PY1552425341153293-211776704",
"title": "URL Rate Limit exceeded",
"httpStatus": 429,
"describedBy": "https://developer.akamai.com/api/core_features/fast_purge/v3.html#httpcodes",
"rateLimit": 10000,
"rateLimitCurrentRequestSize": 110,
"rateLimitRemaining": 94
}
In addition, the API guards against denial of server (DoS) level traffic flows. For example, when a single API client attempts to submit hundreds of requests per second, the API responds with a 400 error for web application firewall (WAF) rate-controlled clients.
HTTP/1.1 400 Bad Request
Content-Length: 427
Date: Thu, 01 Mar 2018 18:46:03 GMT
Connection: close
Content-Type: application/problem+json
{
"type": "https://problems.purge.akamaiapis.net/-/pep-authn/request-error",
"title": "Bad request",
"status": 400,
"detail": "WAF deny rule IPBLOCK-BURST4-27754",
"instance": "https://akab-cj2eq2kcsv7cpt75-bi4ae4mdehbj2p4a.purge.akamaiapis.net/ccu/v3/invalidate/url",
"method": "POST",
"serverIp": "104.76.97.105",
"clientIp": "24.2.26.125",
"requestId": "1dd8d22",
"requestTime": "2018-03-01T18:46:03Z"
}
Resources
This section provides details on the API’s various operations.
API summary
Download the RAML descriptors for this API.
Operation | Method | Endpoint |
---|---|---|
Invalidations | ||
Invalidate by URL or ARL | POST | /ccu/ |
Invalidate by CP code | POST | /ccu/ |
Invalidate by cache tag | POST | /ccu/ |
Deletions | ||
Delete by URL or ARL | POST | /ccu/ |
Delete by CP code | POST | /ccu/ |
Delete by cache tag | POST | /ccu/ |
Invalidate by URL or ARL
Invalidates content on the selected URL or ARL
for the selected network
. You should consider invalidating
content by default. This keeps each object in cache until the
version on your origin server is newer. Deletion retrieves the
object regardless, which can dramatically increase the load on
your origin server and would prevent Akamai from serving the
old content if your origin is unreachable. URLs and ARLs can be
submitted in the same request. Note that it takes longer to purge ARLs when
using the Control Center
interface. Use this API to purge them within five seconds.
POST /ccu/
Sample: /ccu/
Content-Type: application/json
Object type: UrlRequest
Download schema: UrlRequest.json
Request body:
{
"objects": [
"https://foo1.bar.com/some/path",
"http://foo2.bar.com/some/other/path"
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
URL path parameters | |||
network |
Enumeration | production |
The network on which you want to invalidate or delete content, either staging or the default production network. If omitting this optional parameter, also omit any trailing slash from the shortened URL. |
Status 201
application/json
Object type: Response
Download schema: Response.json
Response body:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Invalidate by CP code
Invalidates content on the selected CP
code for the selected network
. You should consider
invalidating content by default. This keeps each object in cache
until the version on your origin server is newer. Deletion
retrieves the object regardless, which can dramatically increase
the load on your origin server and would prevent Akamai from
serving the old content if your origin is unreachable.
POST /ccu/
Sample: /ccu/
Content-Type: application/json
Object type: CpCodeRequest
Download schema: CPCodeRequest.json
Request body:
{
"objects": [
12345,
98765
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
URL path parameters | |||
network |
Enumeration | production |
The network on which you want to invalidate or delete content, either staging or the default production network. If omitting this optional parameter, also omit any trailing slash from the shortened URL. |
Status 201
application/json
Object type: Response
Download schema: Response.json
Response body:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Invalidate by cache tag
Invalidates content on the selected set
of cache tags for the selected network
. You should consider
invalidating content by default. This keeps each object in cache
until the version on your origin server is newer. Deletion
retrieves the object regardless, which can dramatically increase
the load on your origin server and would prevent Akamai from
serving the old content if your origin is unreachable.
POST /ccu/
Sample: /ccu/
Content-Type: application/json
Object type: TagRequest
Download schema: TagRequest.json
Request body:
{
"objects": [
"black-friday",
"electronics",
"laptops",
"tablets"
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
URL path parameters | |||
network |
Enumeration | production |
The network on which you want to invalidate or delete content, either staging or the default production network. If omitting this optional parameter, also omit any trailing slash from the shortened URL. |
Status 201
application/json
Object type: Response
Download schema: Response.json
Response body:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Delete by URL or ARL
Deletes content on the selected URL or ARL
for the selected network
. In most cases, you should
invalidate rather than delete content. URLs
and ARLs can be submitted in the same request. Note that it takes
longer to purge ARLs when using the Control Center
interface. Use this API to purge them within five seconds.
POST /ccu/
Sample: /ccu/
Content-Type: application/json
Object type: UrlRequest
Download schema: UrlRequest.json
Request body:
{
"objects": [
"https://foo1.bar.com/some/path",
"http://foo2.bar.com/some/other/path"
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
URL path parameters | |||
network |
Enumeration | production |
The network on which you want to invalidate or delete content, either staging or the default production network. If omitting this optional parameter, also omit any trailing slash from the shortened URL. |
Status 201
application/json
Object type: Response
Download schema: Response.json
Response body:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Delete by CP code
Deletes content on the selected CP code for
the selected network
. In most cases, you should
invalidate rather than
delete content.
POST /ccu/
Sample: /ccu/
Content-Type: application/json
Object type: CpCodeRequest
Download schema: CPCodeRequest.json
Request body:
{
"objects": [
12345,
98765
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
URL path parameters | |||
network |
Enumeration | production |
The network on which you want to invalidate or delete content, either staging or the default production network. If omitting this optional parameter, also omit any trailing slash from the shortened URL. |
Status 201
application/json
Object type: Response
Download schema: Response.json
Response body:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Delete by cache tag
Deletes content on the selected set of
cache tags for the selected network
. In most cases, you
should invalidate rather
than delete content.
POST /ccu/
Sample: /ccu/
Content-Type: application/json
Object type: TagRequest
Download schema: TagRequest.json
Request body:
{
"objects": [
"black-friday",
"electronics",
"laptops",
"tablets"
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
URL path parameters | |||
network |
Enumeration | production |
The network on which you want to invalidate or delete content, either staging or the default production network. If omitting this optional parameter, also omit any trailing slash from the shortened URL. |
Status 201
application/json
Object type: Response
Download schema: Response.json
Response body:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Data
This section provides details for each type of data object the API exchanges.
Download the JSON schemas for this API.
This section’s data schema tables list membership requirements as follows:
✓ | Member is required in requests, or always present in responses, even if its value is empty or null . |
○ | Member is optional, and may be omitted in some cases. |
UrlRequest
Specifies a list of URLs or ARLs to invalidate or delete. You can submit URLs and ARLs in the same purge request.
Download schema:
UrlRequest.json
Sample POST request:
{
"objects": [
"https://foo1.bar.com/some/path",
"http://foo2.bar.com/some/other/path"
]
}
UrlRequest members
Member | Type | Required | Description |
---|---|---|---|
UrlRequest : Specifies a list of URLs or ARLs to invalidate or delete. You can submit URLs and ARLs in the same purge request. |
|||
objects |
Array | ✓ | Lists URLs or ARLs to purge. Purges content for both http and https schemes. |
UrlRequestWithHostname
Specifies a list of server paths to invalidate or delete for a common hostname
.
Download schema:
UrlRequestWithHostname.json
Sample POST request:
{
"hostname": "origin.qux.com",
"objects": [
"/some/path/object1",
"/some/other/path/object2"
]
}
UrlRequestWithHostname members
Member | Type | Required | Description |
---|---|---|---|
UrlRequestWithHostname : Specifies a list of server paths to invalidate or delete for a common hostname . |
|||
hostname |
String | ○ | Identifies the domain from which the content is purged. |
objects |
Array | ✓ | Lists server paths. Purges content for both http and https schemes. |
CpCodeRequest
Specifies a list of CP codes to invalidate or delete.
Download schema:
CPCodeRequest.json
Sample POST request:
{
"objects": [
12345,
98765
]
}
CpCodeRequest members
Member | Type | Required | Description |
---|---|---|---|
CpCodeRequest : Specifies a list of CP codes to invalidate or delete. |
|||
objects |
Array | ✓ | For CP code-based operations, an array of the CP codes you want to purge. |
TagRequest
Specifies a list of cache tags to invalidate or delete.
Download schema:
TagRequest.json
Sample POST request:
{
"objects": [
"black-friday",
"electronics",
"laptops",
"tablets"
]
}
TagRequest members
Member | Type | Required | Description |
---|---|---|---|
TagRequest : Specifies a list of cache tags to invalidate or delete. |
|||
objects |
Array | ✓ | An array of cache tag strings you want to purge. |
Response
V3 Purge response schema
Download schema:
Response.json
Sample POST response:
{
"httpStatus": 201,
"estimatedSeconds": 5,
"purgeId": "e535071c-26b2-11e7-94d7-276f2f54d938",
"supportId": "17PY1492793544958045-219026624",
"detail": "Request accepted"
}
Response members
Member | Type | Required | Description |
---|---|---|---|
Response : V3 Purge response schema |
|||
describedBy |
String | ○ | A URL that describes the API’s error response. |
detail |
String | ✓ | Detailed information about the HTTP status code returned with the response. |
estimatedSeconds |
Integer | ○ | The estimated number of seconds before the purge is to complete. |
httpStatus |
Integer | ✓ | The HTTP code that indicates the status of the request to invalidate or purge content. Successful requests yield a 201 code. |
purgeId |
String | ○ | Unique identifier for the purge request. |
supportId |
String | ✓ | Identifier to provide Akamai Technical Support if issues arise. |
title |
String | ○ | Describes the response type, for example, Rate Limit exceeded . |
Errors
This section shows you how to handle various kinds of errors the Fast Purge API generates and lists the range of HTTP status codes along with their likely causes.
Error responses
The format of error response objects follows the JSON Problem
Details standard, and are
identified with the application/api-problem+json
content type.
If any object you specify fails to purge, the entire request fails.
This example shows an error response for a request processed by Fast Purge.
{
"supportId": "edup-CUxs8ZxCNNJ6GRdCq5iHXG",
"httpStatus": 400,
"title": "bad URL",
"detail": "Invalid or malformed URL 'https://akamai.com/solutions/devóps.jsp': contains non-ASCII character 'ó' (LATIN SMALL LETTER O WITH ACUTE)",
"describedBy": "https://developer.akamai.com/api/core_features/fast_purge/v3.html#httpcodes"
}
HTTP status codes
The Fast Purge API responds with these standard HTTP response codes:
Code | Description |
---|---|
201 | Successful POST of a purge request. |
400 | Bad request. Often this is an error in the JSON purge request and you’ll want to check all parameters. The API also responds with an error when DoS level traffic for WAF rate-controlled clients exceed the limit of requests per second (see Rate limiting). |
401 | The request requires authentication. Check credentials used to connect to the edge server. |
403 | Forbidden. The authorization token doesn’t allow access to the resource. For example, the request may specify products not authorized on a contract. Check the authorizations for the client and the property configurations purged. |
404 | API endpoint does not exist. |
405 | Disallowed HTTP method. Fast Purge API endpoints accept only POST requests. |
408 | Server timed out waiting for client to produce request. |
410 | Discontinued API version. Please upgrade to Fast Purge API v3. |
411 | No Content-Length header provided. |
413 | Request entity too large. The request was denied because it exceeds the maximum message body size, which is 50,000 bytes. Review your request and edit as needed to be under the 50,000 byte limit. |
415 | Bad media type. Verify that the Content-Type: application/json header is present in the request. |
429 | Too many requests. You exceeded the limit of requests per second (see Rate limiting). Wait five seconds, then retry once there are enough tokens to handle the request. |
500 | Internal server error. |
503 | Service is temporarily unavailable. |
504 | Server timed out while processing request. Wait five seconds, then retry your request. |
507 | Insufficient storage. Wait five seconds, then retry your request. |