Learn
Allow, challenge, or deny API for signup
An allow, challenge, or deny API for signup: decide before granting free credits or an API key, fail closed on timeout, and join outcome feedback (credit burn, conversion) to the original event.
Published 2026-09-15 · Updated 2026-09-15
If you need an allow, challenge, or deny API at signup, you are looking for a trust decision before a costly grant, not another volume cap. The call returns one of three outcomes: allow the action, challenge it with friction, or deny it. On timeout or uncertainty the safe default is challenge, never silent allow.
The decision alone is not enough. Persist the event id from verify on the account row. When the real outcome lands (converted, chargeback, credit burn, banned), send feedback joined on that id so later verdicts on similar traffic get sharper. That loop is what separates a static bot rule from a defense tuned to your free-tier economics.
Where it sits in the stack
Keep rate limits for accidents and burst control. Keep CAPTCHA or Turnstile if you already run them. Add allow, challenge, or deny at consequential actions: signup, trial start, API key issuance, free credit grant. Those are the moments where fake accounts consume credits and never convert.
Chitmark exposes exactly three verbs for this: verify, feedback, and challenge. See the quickstart for the first call, the golden rule for fail-closed behavior, and the comparison page for how this differs from rate limits and Stripe Radar.