Documentation

Content API

The Sanity-compatible HTTP surface: fetching, mutating, document actions, history and the real-time stream.

  1. The API, in one page

    What is served, where, and what makes it Sanity-compatible: same routes, same request shapes, same response envelopes.

  2. Fetching documents

    Queries with parameters, direct document fetches, and the response envelope — including why a query should never be built by string concatenation.

  3. Mutations and transactions

    create, createIfNotExists, createOrReplace, patch and delete — applied as one Postgres transaction, with optimistic concurrency and constraint enforcement.

  4. Document actions

    The transactional form the Studio uses: create, edit, publish, discard, delete and unpublish — each expanding into a mutation set applied as one unit.

  5. History and revisions

    A document at a revision or a point in time, one event per transaction — deletions included — and the raw transaction log.

  6. Real-time listen

    A genuine server-sent-event stream backed by Supabase Realtime, with keepalives, reconnection inside the platform’s time limit, and a polling fallback.