How to make documents with custom prefix private like draft documents

You're correct that documents with a dot (.) in their ID become private in Sanity! This is an important architectural feature that's well-documented.

How the dot-prefix privacy works:

Any document ID containing a . (dot) is considered private and has restricted accessibility. According to the IDs and Paths documentation, these documents can only be accessed when:

• A user is logged in, OR
• A valid authentication token with at least read permission is provided for client/HTTP API calls

The root path (IDs without dots, like myDocument) is publicly accessible, while all subpaths (IDs with dots, like secret.myDocument or drafts.myDocument) are private.

Your secret. singleton pattern:

This is actually a clever use of Sanity's ID system! By using a prefix like secret.mySettings, you're creating a document that:

• Won't be accessible via public/unauthenticated API calls
• Can only be loaded in the Studio (where users are authenticated)
• Follows the same architectural pattern Sanity uses internally for drafts. and versions. prefixes

Important considerations:

1. Avoid drafts. and versions. prefixes - The documentation specifically advises against creating custom documents with these prefixes as they're used internally by Sanity and may interact with platform functionality in unexpected ways.

2. Your custom prefix is fine - Using secret. or any other custom prefix (like config., private., etc.) is a valid approach for private documents.

3. Token requirements - If you ever need to access these documents from client-side code or external APIs, you'll need to provide an authenticated token with appropriate read permissions.

4. Alternative approaches - For more granular control, consider using Sanity's custom access control rules, which give you fine-grained permission control without relying solely on the dot-prefix convention.

5. Dataset considerations - Remember that this privacy mechanism works with Sanity's default access control rules. If you have a completely private dataset, all documents are already protected regardless of their IDs.

This is a practical pattern for singleton configuration documents, settings, or secrets that should only be accessible to authenticated Studio users!