StoneAI API
StoneAI API

API Reference

StoneAI turns a decision into a decree: a model council deliberates over the facts you send, the result is sealed as a SHA-256 content hash, your approver approves or denies it with the scope it requires, and StoneAI Ed25519-signs that decision, bound to the exact content hash, and writes it to your tenant's hash-chained audit ledger. StoneAI records, signs, and notifies your systems by webhook; it does not act inside them. New here? The Quickstart walks the whole loop with curl.

Authentication

  • API key — send Authorization: Bearer sk_live_…. Issued once at POST /v1/signup or POST /v1/keys; only a hash is stored. A revoked key stops working on the next request.
  • Session cookiePOST /v1/login sets an HttpOnly, SameSite=Lax stoneai_sess cookie for the web console. Over a session, revoking keys, inviting or removing team members, and setting the webhook need the owner role.
  • Device login (RFC 8628, for command-line tools) — POST /v1/auth/device returns a user_code valid for 10 minutes; a person approves it at /activate with an existing API key, and the tool polls POST /v1/auth/device/token to receive its own key.

Responses & limits

  • Envelope — every /v1 JSON response is {"success":true,"data":…} or {"success":false,"error":…,"message":…}. /health is raw JSON; /proof/… is HTML.
  • Errors — an invalid key returns 401; a suspended tenant 403; an unknown /v1 route a JSON 404, never an HTML page.
  • Rate limits — counted per tenant (or per IP when unauthenticated) in 60-second windows. Defaults: 120 requests for /v1, 10 for login, signup, and password reset. Over the limit: 429 with Retry-After.
Used only to render the examples in your browser. It is never sent, stored, or logged.
Request bodies in the curl examples are example data — for illustration.
Loading endpoints…