How to Use the Sanity App SDK to Build In-Studio Apps

Your editors keep asking for a button that does not exist. They want to bulk-retag forty articles before a campaign, or tune the system prompt for the support agent without filing a ticket, or see at a glance which product pages are missing translations. Today that work routes to engineering, lands in a sprint, and ships two weeks after anyone needed it. The content team waits, the backlog grows, and the editorial interface stays frozen in whatever shape the original implementation happened to take.

Sanity is the Content Operating System for the AI era, the intelligent backend for companies building AI content operations at scale, and the App SDK is the surface that closes this gap. Instead of accepting the editor you were given, you write the editor your team actually needs as a first-class React application backed by Content Lake. App development on Sanity is not a custom field dropped into a predefined slot; it is a fully customizable React application reading and writing real content with the same governance the rest of your stack already trusts.

This guide covers when an in-Studio app is the right tool, how the App SDK differs from Studio plugins and from competitor extension frameworks, the governance an app inherits for free, and where the pattern pays off. We lead with the workflow problems, then show how Sanity's app surface solves them.

The failure mode: editorial work that has no home in the editor

Every content operation accumulates tasks that fall between the cracks of a generic CMS interface. A merchandiser needs to reorder a curated collection across three locales at once. A localization lead needs to spot which of two hundred documents drifted out of translation sync after the last publish. A support team wants to tune the tone of voice on a customer-facing agent, then preview the change before it reaches production. None of these are exotic. They are the daily texture of running content at scale, and almost none of them fit cleanly into a fixed field-and-form layout.

The usual workaround is to push the task back to engineering. Someone writes a one-off script, runs it against the content API from a laptop, and hopes nobody fat-fingers a dataset. There is no audit trail, no permission gating, and no preview. The editor who actually understands the content is two roles removed from the action, translating intent into a Jira ticket and waiting. When the script is wrong, the blast radius is the whole dataset.

The deeper problem is architectural. A traditional headless CMS treats the editorial interface as a settled artifact: you configure fields, you get a form, and the shape of the work your team can do is bounded by what that form allows. Anything outside the form becomes a side channel, a spreadsheet, a Slack thread, or a maintenance script. The content model is flexible, but the surface that humans touch is not. That mismatch is exactly where in-Studio applications earn their keep, because the right unit of customization is not another field. It is a purpose-built screen with its own logic, reading and writing the same content your editors already manage.

What the App SDK actually is, and how it differs from Studio plugins

The App SDK lets teams build internal tools and custom workflows directly on top of Sanity, as standalone React applications rather than as configuration buried inside a content type. Where a Studio plugin extends the editor you already run (a custom input component, a new pane in Structure Builder, a Presentation Tool overlay), an App SDK application is its own React app that talks to Content Lake through the SDK and can run inside the Sanity Dashboard or be deployed on its own. The mental model shift matters: a plugin reshapes the form, while an app gives you a blank canvas with full access to your content and your design system.

That distinction is why App SDK apps are listed under the "Model your business" capability set, alongside Content Lake, GROQ, the Studio, Visual Editing, and the Dashboard. The app is a way to model a workflow, not just a document. You query content with GROQ, ask for exactly the shape your screen needs in a single round trip, render it however the task demands, and write changes back as real mutations. Because you control the React, you are not limited to the layouts a vendor anticipated. A reconciliation dashboard, a bulk-tagging console, a campaign-staging board: each is a few hundred lines of code against an API you already use.

A practical note on grounding: the public Sanity docs are the authority for exact package names, the app configuration entry point, and the data hooks the SDK exposes, and you should check them against your installed version before you ship. The architectural promise is stable regardless of API surface. You are building a real application, in code, against a managed content store, instead of negotiating with a fixed extension slot.

Governance an in-Studio app inherits for free

The strongest reason to build editorial tooling on Sanity rather than as a standalone script is that the app inherits a governance model you already operate. When an agent or an app acts on content, it acts as the user, not as a privileged system. As the production-context guidance puts it, the agent "inherits your existing security model. Same row-level permissions. Same rate limits. Same regulatory boundaries. You don't build 'AI security' as a separate discipline. You make sure the token flows." The same logic applies to a human-facing app: it operates within Roles & Permissions, so a bulk operation cannot touch documents the operator could not already touch.

That inheritance covers the editorial lifecycle too. Changes an app makes are drafts before they are published, which means scheduling, document history, and Audit logs all apply to work that used to happen invisibly in a terminal. You can stage a change with Content Releases the same way you stage your website, and preview before you ship. The governance you already use for the website, drafts, scheduling, history, permission gating, and audit trails, extends to whatever workflow you build on top.

Contrast that with the maintenance-script approach. A script run against the API from someone's machine has no draft state, no review step, and no record of who changed what. An in-Studio app collapses that gap. The same content team that owns the editorial calendar now owns the tool, and every action it takes is reviewable. For regulated content operations, that difference is the line between a tool you can deploy and one your compliance team vetoes.

A worked example: editors tuning an agent without touching code

Consider a workflow that is increasingly common: a team runs a customer-facing or internal agent whose behaviour is governed by a system prompt and a scope of allowed knowledge. In the naive setup, that prompt lives in YAML in a repository, which means every tweak to tone, every adjustment to what the agent is allowed to talk about, is a code change, a pull request, and a deploy. The people who understand the voice, the content editors, are locked out of the one config that controls it.

Move the prompt into a Sanity document and the dynamic inverts. Nearform, who did exactly this, reported that "storing the system prompt in a Sanity document is genuinely useful. Editors tuned the agent's voice without any code changes." The principle the team named was "author in Studio, not in YAML," so editors tune the agent's voice and the scope of what it knows without touching code. An App SDK app is the natural home for that editing experience: a focused screen that presents the prompt, the allowed-topics scope, and a preview, with none of the surrounding document clutter.

The payoff compounds because the configuration is content, so it gets content governance. Stage the new behaviour with Content Releases, preview it, and ship it on a schedule, with a full history of who changed the agent's voice and when. Update the document once and every surface that reads it, the web experience, a co-working tool, downstream apps, and customer-facing agents, stays in sync. The app is the interface; the content model is the source of truth; the governance backbone is the one you already trust for the website.

When to build an app, when to write a plugin, and when to do neither

Not every customization wants to be an app. The decision turns on the shape of the work. If you need to change how a single field behaves while editing a document, an in-line validation, a custom color picker, a reference selector with a smarter query, that is a Studio plugin or a custom input component. It belongs inside the editing form because that is where the editor is looking. Reaching for a separate app there adds navigation cost for no benefit.

Build an App SDK app when the work is a task in its own right rather than an edit to one document. Cross-document operations are the clearest signal: bulk retagging, a translation-coverage dashboard, a campaign-staging board that spans dozens of references, an editorial analytics view, or the agent-config screen from the previous section. These need their own layout, their own state, and often their own GROQ queries that project across many documents at once. A form cannot express them; an application can.

And sometimes the answer is neither. If the operation is a content transformation rather than an interface, generating alt text, translating a field, enriching a record, the right tool is Functions or an Agent Action invoked from an existing workflow, not a screen a human babysits. The art is matching the surface to the job: plugins reshape the form, apps model a workflow, and Functions automate a transformation. The App SDK earns its place precisely when a human needs a purpose-built screen to drive content work that no form was ever going to hold.

How the app surface compares across headless platforms

The in-editor app pattern is not unique to Sanity, and an honest comparison says so. Contentful's own "App building with AI" tutorial walks developers through using the App Framework plus React to build sidebar apps inside the CMS, and Directus ships a third-party AI Researcher extension that embeds a chat UI directly in the editor. Payload, being code-first and TypeScript-native, lets you customize the admin UI with React components and add AI completions through a plugin. The capability to put custom UI next to content exists across the category.

Where the platforms diverge is the degree of control and what you have to operate to get it. Contentful's apps live in predefined slots within a fixed layout, so you are decorating a UI you do not own. Strapi and Payload give you deep customization, but you also own the host, the database, and the infrastructure that runs underneath. Directus leans on its Flows and extension model rather than a first-party React application SDK. Sanity's distinction is a fully customizable React surface against a managed Content Lake, with editorial governance built in rather than bolted on. The comparison table below lays out the trade-offs so you can weight them against your own constraints.