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 atPOST /v1/signuporPOST /v1/keys; only a hash is stored. A revoked key stops working on the next request. - Session cookie —
POST /v1/loginsets an HttpOnly, SameSite=Laxstoneai_sesscookie 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/devicereturns auser_codevalid for 10 minutes; a person approves it at/activatewith an existing API key, and the tool pollsPOST /v1/auth/device/tokento receive its own key.
Responses & limits
- Envelope — every
/v1JSON response is{"success":true,"data":…}or{"success":false,"error":…,"message":…}./healthis raw JSON;/proof/…is HTML. - Errors — an invalid key returns
401; a suspended tenant403; an unknown/v1route a JSON404, 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:429withRetry-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…