Handling 428 Status Code (SEC-CPT)
Understanding SEC-CPT Blocks
When interacting with APIs protected by Akamai, you may encounter a 428 Precondition Required status code. This indicates that you have triggered a challenge that must be solved before you can continue making requests.
The challenge response contains a JSON payload with provider-specific information:
{
"sec-cp-challenge": "true",
"provider": "crypto",
...
}The provider field determines which challenge flow you need to follow. The two most common providers are:
crypto - A proof-of-work challenge with a mandatory wait duration
behavioral - A behavioral analysis challenge requiring normal sensor data
Key Cookie
The sec_cpt cookie is the primary indicator of challenge status. A successfully solved challenge will result in a sec_cpt cookie containing ~3~ in its value.
Crypto Provider
The crypto provider implements a proof-of-work challenge with a mandatory wait duration that cannot be bypassed.
Challenge Response Structure
When you receive a crypto challenge, the response contains:
sec-cp-challenge
Always "true" indicating an active challenge
provider
"crypto" for this challenge type
branding_url_content
Path to the challenge page (e.g., /_sec/cp_challenge/crypto_message-4-3.htm)
chlg_duration
Mandatory wait time in seconds
token
Challenge token for payload generation
timestamp
Server timestamp
nonce
Cryptographic nonce
difficulty
Proof-of-work difficulty parameter
timeout
Challenge timeout value
Solution Flow
Step 1: Parse the Challenge
Extract the challenge data from the 428 response. The response can come in two formats:
HTML format: Contains an iframe with
challengeattribute (base64-encoded JSON),data-durationattribute, andsrcattribute for the challenge pathJSON format: Direct JSON response with all challenge parameters
Step 2: Wait the Required Duration
You must wait for the duration specified in chlg_duration (or data-duration in HTML format). This wait time is enforced server-side and cannot be bypassed or shortened.
Step 3: Generate and Submit the Proof-of-Work Payload
After waiting, generate the proof-of-work payload containing:
The challenge
tokenComputed
answersbased on the challenge parameters (nonce, timestamp, difficulty)
Submit this payload via POST to /_sec/verify?provider=crypto on the target domain.
Step 4: Verify the Challenge
Make a GET request to /_sec/cp_challenge/verify to complete the verification process.
Step 5: Validate Success
Check that the sec_cpt cookie now contains ~3~ in its value. If not, the challenge was not successfully solved.
Behavioral Provider
The behavioral provider requires sensor data submission, similar to standard Akamai sensor flow but with a different endpoint structure.
Challenge Response Structure
sec-cp-challenge
Always "true" indicating an active challenge
provider
"behavioral" for this challenge type
branding_type
Branding configuration type
branding_cust_url
Path to the challenge branding page
verify_url
Dynamic verification URL path (unique per challenge)
Solution Flow
Step 1: Fetch the Branding Page
Make a GET request to the branding_cust_url path (e.g., /challenge.html) on the target domain. This page contains the script endpoint needed for sensor submission.
Step 2: Extract and Fetch the Script
Parse the branding page response to locate the Akamai script endpoint. Make a GET request to fetch the script content - this is required for sensor generation.
Step 3: Submit Sensor Data
Generate and POST sensor data to the script endpoint. Key considerations:
Use a fresh sensor context for this challenge (do not reuse context from previous requests)
While one sensor POST is often sufficient, implement a loop of up to 3 sensor posts
Break out of the loop early if the
sec_cptcookie is set (indicates sufficient sensor data was received)Include the
_abckcookie value in sensor generation
Step 4: Verify the Challenge
Make a GET request to the verify_url path returned in the original challenge response. Note that this is a dynamic path unique to each challenge, not the static /_sec/cp_challenge/verify endpoint used by the crypto provider.
Step 5: Validate Success
Confirm that the sec_cpt cookie contains ~3~ in its value.
Implementation Best Practices
Header Ordering
Maintaining correct header order is critical for both challenge types. Akamai's protection systems analyze header ordering as part of their fingerprinting. Always ensure your HTTP client preserves the exact header order you specify.
Cookie Management
sec_cpt: Primary challenge status cookie - monitor for~3~to confirm successbm_sz: Akamai bot manager cookie - required for sensor generation_abck: Akamai bot manager cookie - required for sensor generation
Properly store and forward cookies between all requests to maintain session state.
Session Consistency
Use the same User-Agent throughout the entire challenge flow
Maintain consistent client hints (
sec-ch-ua,sec-ch-ua-mobile,sec-ch-ua-platform)Keep TLS fingerprint consistent across all requests
Handling Challenges in API Flows
SEC-CPT challenges can appear in two contexts:
Initial page load: The challenge appears when first accessing a protected page
During API calls: A previously valid session may receive a 428 response, requiring challenge resolution before retrying the original request
Implement automatic challenge detection and solving in your API client to handle both scenarios seamlessly.
Error Handling
If the
sec_cptcookie does not contain~3~after completing the flow, the challenge was not successfully solvedFor behavioral challenges, if sensor posts don't result in a
sec_cptcookie after 3 attempts, the implementation is most likely incorrectFor crypto challenges, ensure you wait the full duration before submitting - premature submission will fail
Quick Reference
Wait Required
Yes (mandatory)
No
POST Endpoint
/_sec/verify?provider=crypto
Script endpoint from branding page
Verify Endpoint
/_sec/cp_challenge/verify (static)
Dynamic verify_url from challenge
Success Indicator
sec_cpt contains ~3~
sec_cpt contains ~3~
Typical Posts
1 (after wait)
1-3 sensor POSTs
Last updated