API documentation

Every request needs an API key issued by Glassnode, sent as a Bearer token. Keys look like tk_live_… and are shown once when created. A key in a query string is rejected. Request a key on the API access page.

curl -sS -H "Authorization: Bearer $TOKENIZATION_API_KEY" https://tokenization.glassnode.com/api/v1/changes/head

Responses carry X-Request-Id, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset and the daily X-Quota-Daily-* headers. Quote the request id when reporting a problem.

1. Call GET /snapshot once. It streams the whole registry and includes a cursor.
2. On a schedule, call GET /changes?since=<cursor>. Each event carries the entity’s current record.
3. Apply events as upserts keyed by entity_type and entity_id; treat op: deleted as a removal.
4. Store next_cursor, and keep paging while has_more is true. A page can carry zero events while has_more is true, because limit counts underlying audit rows, so loop on has_more, never on the event count.

Delivery is at-least-once: an entity touched across a page boundary can appear twice, always with its current state, so upserts are safe to repeat. Changes to embedded data surface on the parent as well: a deployment or provenance change produces a deployment event and an updated event for its product; a document or listing change updates the issuer or product; an issuer listing change also updates the venue. Events appear once every older database transaction has finished, so a long ingestion run can delay the feed by minutes. Cursors never expire, except that a cursor from an earlier feed epoch (after a database restore) is rejected with invalid_cursor, which means take a new snapshot.

• Every record has an id: a lowercase slug assigned by the registry, such as coinbase, aaplc or ul-aapl. Ids never change and are never reused. Key your storage on entity type plus id.
• Retirement is a status, not a deletion. A product, deployment or derivative that an issuer winds down stays in the data with status: inactive; deployments can also be deprecated.
• An event with op: deleted means a record was removed outright, which is rare and means a correction or a de-duplication. Its record holds the last known top-level fields when available and null otherwise; treat both as “remove this id”.
• null means the registry has not established a value. In the issuer fields custodian, governing law and regulator, not disclosed means the issuer’s documents were read and name none, and None (…) means the structure has none, with the reason. Several custodians are joined with “ / ”.
• Fields may be added within v1; none are removed, renamed or retyped. Ignore unknown fields.
• The snapshot holds about 5,800 products and 21,600 deployments as of October 2026, roughly 15 MB of JSON and a few MB gzipped.

• 300 requests per minute and 50,000 per day per key by default, counted on the server clock in UTC.
• A snapshot counts as 50 requests and is limited to 10 per key per day. At most two snapshots are generated at once.
• Limited responses return 429 with Retry-After in seconds and do not count toward the quota.
• Only GET is supported. Responses are JSON (the snapshot is gzip-compressed when the client accepts gzip) and are sent with Cache-Control private, no-store; list and detail responses still carry an ETag for If-None-Match, and a 304 counts as a request.

Errors return { "error": { "code", "message", "request_id" } }.

Field names match the site’s vocabulary. Timestamps are ISO 8601 in UTC. Retired products and deployments stay in the data with status: inactive. The full JSON Schema for every record is in the OpenAPI definition.