Request tags

Request tags in Sanity Log Delivery can be added to API and CDN requests for filtering and aggregating log data, supported by @sanity/client.

Request tags are values assigned to API and CDN requests that can be used to filter and aggregate log data within request logs from your Content Lake. The tagging can be achieved by adding the tag query parameter to the request URL, typically in the format:

GET /data/query/<dataset>?query=<GROQ-query>&tag=<custom-defined-tag>

@sanity/client has out-of-the-box support for tagging every API and CDN request on two levels:

• Globally: Using the requestTagPrefix client configuration parameter.
• Per request: Pass the tag option to the SDK’s request method.

This provides a flexible method for tagging requests:

The following example will result in a query with tag=website.landing-page.

const client = createClient({
  projectId: "<project>",
  dataset: "<dataset>",
  token: "",
  useCdn: false,
  apiVersion: "2024-01-24",
  requestTagPrefix: "website" // Added to every request
});

const posts = await client.fetch(
  '*[_type == "post"]',
  {}, // Query parameters
  {tag: "landing-page"} // Appended to requestTagPrefix for this individual request
);

Sanity's own clients tag their requests too, so your logs contain tags you never set.

Sanity Studio sets sanity.studio as its requestTagPrefix, and each subsystem adds its own tag on top. The two are joined with a dot, following the same rules as your own prefixes and tags above, so the Tasks store's tasks-store tag reaches your logs as sanity.studio.tasks-store.

Studio tags you're most likely to see:

• sanity.studio.preview.observe-document-set.listen: the preview system keeping document lists in sync. This is usually the highest-volume Studio tag.
• sanity.studio.tasks-store: the Tasks feature.
• sanity.studio.documents.history and sanity.studio.transactions-log: document history and the transaction log.
• sanity.studio on its own: requests that carry only the prefix, such as the real-time collaboration socket.

The list isn't fixed: Studio subsystems add and rename their tags between releases, so treat the whole sanity.studio namespace as first-party rather than matching on exact tags.

A tag is a query parameter the client adds to the URL before it sends the request. Nothing ties it to the caller's identity, and any client can send any value. @sanity/client checks only that the value is 75 characters or fewer of letters, digits, dots, dashes, and underscores.

So a request tagged sanity.studio.preview.observe-document-set.listen that returned 401 was rejected as unauthenticated. The tag tells you what kind of client claims to have sent the request, not whether it signed in successfully. When you audit logs, read the tag and the status code together.

For what those failed requests mean for your bill, see plans and payments.