What makes a token risk API machine-readable?

Schema over prose

Agents need to know whether a field is boolean, nullable, bounded, or required. They also need to know what happens when a source is unavailable. Free-form text alone makes policy enforcement brittle.

Jepeta publishes the canonical V5 POST contract in openapi-v5.json, with a separate V4 GET compatibility contract. Agent manifests, LLM files, methodology and changelog document the different surfaces. An API generation, response schema and methodology version identify different layers and should not be treated as one version number.

Unknown values must stay unknown

A machine contract should distinguish false from unavailable and zero from missing. Otherwise a downstream system can convert data gaps into false reassurance.

Jepeta fails closed on required honeypot/mintability unknowns and keeps optional unavailable metrics null with source-status context.

Stable evidence helps verification

Permanent evidence pages add a canonical HTML and JSON representation for selected published snapshots. That gives search engines and agents a durable reference separate from the live scan endpoint.

The durable snapshot still includes a last-checked timestamp and a link to run a fresh scan.

Use negative cases to test the consumer

Before accepting an integration, submit synthetic consumer fixtures for a missing verdict, an explicit NO_VERDICT, a wrong contract, a wrong chain and an unavailable optional metric. The first four must not become a usable policy decision. The optional metric must remain unknown rather than zero. These are proposed parser checks, not live API observations. Keep the response schema version distinct from the methodology version when recording the outcome.

Practical checklist

• Versioned schema
• Typed required fields
• Explicit null semantics
• Bounded errors
• Canonical identity
• Methodology + changelog
• Timestamped evidence

Limitations