Introduction

Start with signup and free-credit farming: measure abuse on your own traffic, then put proportional friction in front of actions that would otherwise consume the grant.

Chitmark runs alongside your existing auth and abuse controls. Outcomes are reported afterward and joined to the original decision using eventId. Credit burn, conversion, and chargeback are labels for review, not a payments or billing product.

The loop

One loop, several surfaces.

The baseline, economics, farming analysis, and Agent Farming Ledger all use the same verify → act → feedback loop.

              ┌──────────────┐
              │    verify    │
              └──────┬───────┘
                     ↓
             allow / challenge / deny
                     ↓
                  action
                     ↓
              ┌──────────────┐
              │   feedback   │
              └──────┬───────┘
                     ↓
           future decisions

A challenge verdict routes the action through your configured friction before the action can consume the grant. allow proceeds; deny stops.

Three verbs

verify can return decision: "challenge". That means friction is warranted, not that friction has been applied or satisfied. Return HTTP 428, then POST /v1/challenge to issue instructions (no proof), have the client satisfy them, and complete with challengeId + proof to prove friction was satisfied. You can also run your own step-up and skip the endpoint; the verb is there when you want Chitmark to generate and validate the challenge. Prefer ranked methods by friction economics.

Contract source

OpenAPI 3.1 is the source of truth.

The HTTP API is defined in the OpenAPI 3.1 contract. These docs, SDKs, and examples follow that machine-readable specification.

Operational contract

Trust and ops pages live next to the API docs: