Skip to main content
ZeroClick forwards every paid request, and every unpaid probe, from its own servers to your upstream base URL. A firewall, CDN, or bot-protection layer in front of that URL sees automated traffic from a cloud provider’s address space with no browser behind it, which is what bot protection exists to challenge. This page covers what a challenge does to a purchase and how to exempt ZeroClick’s forwards without opening those paths to anyone else.

What a challenge does to a purchase

Bot protection answers a request it distrusts with a challenge in place of your response: usually a 403 carrying an HTML page (Vercel’s Security Checkpoint, Cloudflare’s “Just a moment” interstitial) that a browser passes by running JavaScript. ZeroClick does not solve challenges. It returns your upstream’s status and body to the buyer unchanged, so the agent receives an HTML checkpoint where it expected a 402 or your JSON, and reports the purchase as failed. Nothing on your side records an error, because the request never reached your handler. Signs that this is happening:
  • An agent reports a security checkpoint, a bot check, or a 403 from your pay URL on a route that answers JSON.
  • The failures are intermittent. One probe passes, the next is challenged.
  • Your own logs show no request for the failed call.
Volume makes it more likely. ZeroClick forwards a signed anonymous probe for every unpaid pay-as-you-go call, then the paid retry, and it probes each endpoint when it builds your catalog. To a bot detector, a busy storefront looks like a scripted flood from one place.

What to key the exemption on

Match on the presence of zc-signature, and scope the rule to the paths ZeroClick calls: the endpoint paths in your catalog, which are the paths agents request on your pay URL and which ZeroClick forwards to the origin of your upstream base URL, plus /zeroclick/access and everything under it if you sell accounts and API keys. The rest of your site keeps its protection. One fetch carries no signature: the OpenAPI document ZeroClick downloads from your store’s OpenAPI URL when it imports your catalog. If that document sits behind the same challenge, exempt its path on its own. It is public by design.

Why the exemption is safe

Anyone can put a zc-signature header on a request, so the rule lets unverified traffic past the bot check on the exempted paths. That traffic then meets your guard, which recomputes the HMAC with your signing secret and answers 401 {"error":"invalid_zeroclick_signature"} before your handler runs. A forged header trades a challenge page for a 401 and nothing more. The guard was always the gate. The exemption stops a second gate from refusing the traffic the first one was built to check. See verify requests. Rate limits are a different control. One sized for real buyer volume can stay in place. A challenge action cannot, because no forward can pass it.

Platform recipes

Vercel’s Bot Protection managed ruleset challenges non-browser traffic, and Vercel notes that direct API calls cannot pass the challenge. Its documented exemption for trusted automation is a WAF custom rule with the Bypass action.
  1. In the project, open Firewall, then Configure, then Add New and Rule.
  2. Add the condition Header zc-signature Exists. Add a second condition with AND: Request Path Starts with the path ZeroClick calls, for example /api/.
  3. Set the action to Bypass, save the rule, and publish the change. If you have Challenge rules of your own, place this rule above them. Custom rules run in order, and the managed rulesets run after them.
Bypass skips the remaining custom rules and the managed rulesets, including Bot Protection. It does not skip system-level DDoS mitigation. Attack Mode is separate: it challenges every request that is not a verified bot or a call from your own Vercel Functions and Cron Jobs, and Vercel does not list custom Bypass rules among its exemptions. Leave Attack Mode off while you sell through ZeroClick.

Confirm the rule

From outside your network, send a request with a made-up signature to a guarded route:
The right answer is the guard’s 401 {"error":"invalid_zeroclick_signature"}: the request passed the firewall and verification refused it. A 403 or an HTML body means the challenge still applies. Then send an unpaid request to the same route on your pay URL. A 402 with a payment challenge confirms the probe reached your guard.