Content hash

What it is

A hex digest computed over the frozen schema content for a version. Same inputs → same hash. Different inputs → different hash. The server never emits a partial or best-effort hash.

Stable versions have a content hash that never changes once promoted. Beta versions emit the current hash on each read; the hash only changes when an author rebuilds the schema.

Where it appears

REST, version-scoped endpoints:

HTTP/1.1 200 OK
Content-Type: application/json
DTPR-Content-Hash: sha256-f8a2…

MCP envelopes — inside meta:

{
  "ok": true,
  "data": { "...": "..." },
  "meta": { "content_hash": "sha256-f8a2…", "version": "ai@2026-04-16-beta" }
}

Why agents care

An AI agent that caches DTPR content (element titles, category structure, rendered HTML) can use the content hash as a cache key:

cache_key = content_hash

When the next response carries a different content_hash, the cache entry is stale — invalidate and re-fetch. No polling, no version number parsing, no "every 5 minutes check if the schema moved."

Not a crypto signature

The hash is a fingerprint, not a signature. It detects drift; it does not authenticate origin. If you need authenticated content, rely on TLS to api.dtpr.io.

Beta churn

A beta version's content hash changes on every rebuild. If your client pins on the hash against a beta version, expect cache turnover during active authoring. Pinning on a stable version's hash gives you an immutable handle.

See also

• Versions & releases
• MCP envelope
• REST conventions — response headers.