In the configurations section for Cloudflare Turnstile, they list a cData (or data-cdata) option:
A customer payload that can be used to attach customer data to the challenge throughout its issuance and which is returned upon validation.
I am having trouble thinking of why & when such a parameter would be used. Why include some data here rather than in your eventual API call when you send the Turnstile token header?
At first I thought it was to create a non-standard setup to make it harder for those using captcha-solving services, but I see that those services include this parameter in their API.
Why else would one use this parameter?
Broadly speaking, cData is used to encode lightweight, verifiable context about:
The user
The action
The origin
The moment
That context can be used to validate, debug, or trace. Some specific use cases might be:
User session or ID tagging
Form identification
Form intent fingerprinting
Timestamping
Tracking UTM source or campaign ID
A/B test tagging
You are correct that captcha-solving services include a cData parameter; however, they do not know what it actually represents. cData is an opportunity to embed meaningful context into the challenge. When the token is validated server-side, you can check that the context matches what you expect. This helps ensure that the token wasn't generated by a bot / agent, but came from the right environment and purpose.
For example, even if a token will technically pass the siteverify (such as when a challenge was solved by a bot / agent or the token was reused from somewhere else), if the cData doesn't match your server-side expectations, you can reject the request independently of whether the token passed. This is similar to HMAC in that we tie the token to the intent and origin.
cData can also be thought of as a way to deploy a manual, customizable version of Cloudflare Ephemeral IDs, allowing you to tie Turnstile tokens to specific users, forms, or sessions in a lightweight way without needing an Enterprise plan.
Another idea is that cData may be relevant in some enterprise scenarios. Because Cloudflare stores the cData in the validation payload, it (presumably) becomes part of the auditable challenge trail on their end (in addition to yours). This may be useful when working with Cloudflare to debug submissions, investigate fraud, support abuse reports, or aid in forensic analysis.
In summary, cData is effectively a fingerprint on a challenge that is signed by Cloudflare which is:
Client-side initiated
Server-side verifiable
Not dependent on trusting the rest of the request body