FAQ

Who should own the Sanity project and organization when an agency builds it?

Short answer

The client's organization is the right owner of a Sanity project an agency builds, in Deploi's view, because Sanity attaches payment methods to the owning organization (Sanity Docs, October 2026). Sanity lets only that organization's Administrators and Billing managers add one (Sanity Docs, October 2026), so the client holds those roles, pays Sanity directly and invites the agency in.

Who pays Sanity
The organization that owns the projectPayment methods belong to the owning organization; only its Administrators and Billing managers can add one, and project roles grant no billing accessSources: Sanity Docs (Plans and payments, Projects, organizations, and billing)
Organization-level since spring 2025
Media Library, Functions compute, Content ReleasesSanity's guide for agencies says these are shared, managed and priced per organization, so one agency organization holding many clients mixes their usage and billsSources: Sanity Docs (Agencies: Navigating the Spring 2025 organization changes, Functions, Content Releases user guide)
Who can transfer a project
An Administrator of the project and source organizationThe receiving side can be a Billing manager, Administrator or Developer; without billing rights in both, a Billing manager in the receiving organization approvesSources: Sanity Docs (Plans and payments, Agencies: Navigating the Spring 2025 organization changes)
Robot token lifetime
Until deleted, by defaultSanity's docs say expiry dates can be set on new or existing tokens since June 2026; personal tokens last up to a year without interventionSource: Sanity Docs (Authentication and tokens)

Deploi’s call

Your organization should own the Sanity organization and the project from day one and pay Sanity directly, with the agency invited in as a project member. Deploi recommends this for every production project, because in Sanity the organization that holds a project holds its payment method, its organization-level usage and the right to move it.

YesOwn the Sanity organization and project yourself when

  • The project runs on a paid plan, because Sanity bills the organization that owns it and only its Administrators and Billing managers can add a payment method, as of October 2026.
  • You'll use Functions, Media Library or Content Releases, which Sanity has managed and priced at the organization level since spring 2025 (Media Library and Content Releases are Enterprise add-ons as of October 2026).
  • You might change agencies or bring the work in-house, so the account, the bill and the tokens stay with you when the agency leaves.

DependsLet an agency hold a Sanity project only while

  • It's a throwaway proof of concept on the Free plan with no customer data, as of October 2026.
  • A transfer into your organization is a dated step in the contract, so it happens before any paid plan or launch.
  • You hold Administrator on the project from day one, so the agency is never the only Administrator who can manage members and tokens; starting the transfer still needs an Administrator of the agency's organization.

Why should the Sanity organization and project be yours, not the agency's?

The Sanity organization and project should be yours because, in Sanity, the organization that holds a project pays for it and can move it. That holds whichever you hire: an agency, a freelancer or an in-house team.

Sanity's documentation is specific:

  • Paid plans require the project to belong to an organization, which pays (Sanity plans and payments, October 2026).
  • Payment methods belong to the organization that owns the project, and only its Administrators and Billing managers can add one; project roles grant no billing access (Sanity Docs, October 2026).
  • The organization Administrator role manages billing, members and project ownership (Sanity Docs, Roles and permissions, October 2026).

So create the project in, or move it to, your organization before the build starts, pay Sanity directly and invite the agency in. Deploi's Sanity development service recommends that setup and estimates each job in hours for your written approval (Deploi, Pricing, October 2026). Put ownership among the terms to insist on with a Sanity agency; legal ownership of code and content is for your counsel.

Why did Sanity's spring 2025 changes make organization ownership matter more?

Since Sanity's spring 2025 release, Media Library, Functions compute and Content Releases are shared, managed and priced at the organization level (Sanity's guide for agencies, October 2026); Media Library and Content Releases are Enterprise add-ons as of October 2026. An agency that keeps many clients' projects in one Sanity organization shares those resources and their costs across every client, which Sanity says "can lead to inefficient resource allocation, mix-ups, and billing challenges" (Sanity's guide for agencies).

Three mechanics make the mix real:

  • Compute. Sanity Functions usage, invocations and GB-seconds, is metered across every function in the organization rather than per project (Sanity plans and payments; Sanity Docs, Functions, October 2026).
  • Invoices. All projects in an organization are invoiced and charged together on the first of each month (Sanity plans and payments).
  • Shared assets. Media Library, an Enterprise add-on, stores an organization's assets for use across its projects (Sanity Docs, Meet the library, October 2026), so clients would share one library.

Sanity's guide for agencies says: "Always create client-specific organizations from the start for new projects" (Sanity's guide for agencies). Sanity's terminology page says splitting one implementation across organizations is rarely required, only when projects need different payment methods (Sanity Docs, Platform terminology, October 2026). Both are true: the terminology page is about one company's projects, and an agency's clients are different payers.

What access does the agency need in your Sanity project, and what should stay with you?

The agency needs a project role, not a role in your Sanity organization. Project Administrators reach datasets, members, tokens and webhooks (Sanity Docs, October 2026), and a project Developer reads and writes all datasets with developer settings (Sanity Docs, Roles, October 2026). Project roles imply organization-level Media Library and Canvas roles; billing roles stay with your people.

The agency works in your Sanity project; organization roles stay yours
Sanity roleWho holds itWhat the role can do
Organization AdministratorTwo of your own peopleBilling, members and project ownership
Organization Billing managerYour finance contactBilling details and attaching projects
Organization DeveloperNobody, or the agency lead for a transferAttaching projects, organization-wide tokens
Project AdministratorYour people, plus the agency lead while buildingDatasets, members, tokens and webhooks
Project DeveloperThe agency's developersRead and write on all datasets
Project ViewerReviewers who only readRead-only; uses no paid seat
Who holds each role is Deploi's recommendation.Sources: Sanity Docs (Roles and permissions, Platform terminology, Roles, Authentication and tokens). As of 24 October 2026.

The Free plan has only Administrator and Viewer, so Developer needs Growth or Enterprise as of October 2026 (Sanity Docs, Roles). Each agency member above Viewer takes a seat that Growth charges individually (Sanity pricing, October 2026), so count them in what Sanity will cost you.

How do you move a Sanity project an agency already owns?

You move a Sanity project with a project transfer: an Administrator of both the project and the agency's organization starts it, and that person needs a Billing manager, Administrator or Developer role in your organization (Sanity plans and payments, October 2026).

Transfer a Sanity project into your organization

  1. Create your organization. Add your payment method and make your own people its Administrators; either side may create it (Sanity's guide for agencies, October 2026).
  2. Give the agency lead a receiving role. Invite that person into your organization as a Developer, because the transfer needs a role on both sides.
  3. Start the transfer. The agency lead opens the project's settings in Sanity Manage and selects your organization.
  4. Approve it. It's instant with billing rights in both organizations; otherwise a Billing manager in yours approves (Sanity's guide for agencies).
  5. Check the bill, then tidy roles. Billing is prorated for the month, your organization pays any overage the project has accrued, and the plan and quotas stay the same (Sanity plans and payments). Then remove the agency lead's organization role.

Sanity suggests transferring at the start of a billing cycle (Sanity's guide for agencies). If you need only a copy of your content, not the project, exporting all content from Sanity is the other route.

How do you offboard an agency or former staff from Sanity?

You offboard an agency or a leaver from Sanity by removing their roles and deleting or expiring every token they created.

Offboard an agency or a leaver from Sanity

  1. Secure your own Administrator first. Sanity blocks the only Administrator from leaving a project or an organization, so promote one of your people first (Sanity Docs, October 2026).
  2. Remove their roles. Take away their project roles (Sanity Docs, October 2026) and any organization role they hold.
  3. Delete or expire their robot tokens. Sanity's docs say robot tokens last until deleted by default, with an optional expiry date since June 2026 (Sanity Docs, October 2026). Check organization-wide tokens too: they reach several projects, Media Library and Canvas.
  4. Replace what used them. Issue a new token for each app that used a deleted one, because Sanity shows a token only once (Sanity Docs).
  5. Close the single sign-on gap. With SAML (Security Assertion Markup Language) single sign-on, dropping someone in your identity provider stops their next login but doesn't remove their Sanity account (Sanity Docs), so remove their roles in Sanity too. Sanity's pricing page lists SAML as Enterprise as of October 2026.

A personal token lasts up to a year without intervention (Sanity Docs), so remove roles the day someone leaves, as part of keeping Sanity tokens and access under control.

Deploi’s point of view

Where we disagree
The common advice treats Sanity ownership as a launch-day handover item. In Sanity the organization that holds the project is billed from the first invoice: a project that starts in an agency's organization has to be transferred, with prorated billing and any accrued overage, before you control it. The second mistake is reading Sanity's line that splitting one implementation across organizations is rarely required as advice for agencies. That line is about one company's projects; Sanity's own guide tells agencies to create client-specific organizations from the start.
What this adds
The parent page decides who to hire for Sanity work. This page decides who holds the Sanity organization, the bill and the tokens whichever you hire, and gives the transfer and offboarding steps.
What we'd tell you to do first
Before the build starts, create your Sanity organization, add your payment method and name two of your own people as organization Administrators. Then create the project in, or move it to, that organization and invite the agency into the project. If the agency lead needs a role in your organization for a transfer, give it for the transfer and remove it after.
Where we would push back
If an agency proposes to build a production Sanity project in its own organization and hand it over at launch, we'd push back, because the transfer is a step someone has to remember, and until it happens the agency's organization holds the bill and the organization-level usage.
How we scope it
Deploi estimates each job in hours, and you approve the estimate in writing before work starts. Put ownership in that estimate: name your organization as owner of the Sanity organization and project, and of the code repository, hosting account, domain and third-party API keys, which sit outside Sanity; then list the same items in your handover checklist. We don't give legal advice on intellectual property or data protection terms; that belongs with your counsel.

When this answer changes

  • Sanity changes which roles can start or approve a project transfer
  • Sanity moves more features or quotas to the organization level, or changes how organizations are invoiced
  • Sanity makes an expiry date the default for robot tokens
  • Sanity starts removing accounts automatically when a SAML identity provider drops a user
  • Sanity changes whether Viewer roles use a paid seat

Sources

Every source opened and checked on 25 October 2026.

  1. Sanity Docs, Agencies: Navigating the Spring 2025 organization changessanity.io · checked 24 October 2026
  2. Sanity Docs, Plans and paymentssanity.io · checked 24 October 2026
  3. Sanity Docs, Projects, organizations, and billingsanity.io · checked 24 October 2026
  4. Sanity Docs, Roles and permissionssanity.io · checked 24 October 2026
  5. Sanity Docs, Authentication and tokenssanity.io · checked 24 October 2026
  6. Sanity Docs, Platform terminologysanity.io · checked 24 October 2026
  7. Sanity Docs, Functionssanity.io · checked 24 October 2026
  8. Sanity Docs, Rolessanity.io · checked 24 October 2026
  9. Sanity, Plans that scale with yousanity.io · checked 24 October 2026
  10. Sanity Docs, Reconcile users against internal systemssanity.io · checked 24 October 2026
  11. Sanity Docs, Meet the librarysanity.io · checked 24 October 2026
  12. Deploi, Pricingdeploi.ca · checked 25 October 2026
  13. Sanity Docs, Content Releases user guidesanity.io · checked 24 October 2026