Skip to main content
A write key authorizes event ingestion into one Glyph workspace. It cannot read customer data. A browser key is public, so anyone who obtains it can send unwanted events or consume workspace limits. Keys live in your workspace’s Settings page.

​
Key purpose

When you create a key, choose its intended use: Server, Browser, Direct HTTP, Backfill, or Other. Glyph records that purpose with each ingest request. Use separate keys for separate channels so the credential provides reliable provenance even when client metadata is missing. The purpose identifies how you configured the credential, not a security guarantee about the program using it. Anyone with a valid key can send an HTTP request with that key.

​
Live and test keys

The environments are separate. Test profiles, events, and timelines do not appear in the live workspace view, and live data does not appear in test. Use test keys for development and staging builds. SDKs validate the prefix at construction and refuse keys that don’t start with either one. The server enforces the same boundary: a key only ever ingests into the environment its prefix names.

​
Test environment limits

The test environment is for integration checks. Once it contains 5,000 stored events, further ingest requests return 403. The check runs before a batch commits, so the final accepted batch can take the total slightly above 5,000. Clear test data from Settings or switch to a live key. If you’re dry-running a large backfill, sample your data rather than replaying all of it against the test environment.

​
Reveal and rotation

Glyph shows a key’s full value once, when it is created or rotated. Copy it at that point. Store server keys in an environment variable such as GLYPH_WRITE_KEY, not in code. Settings shows who created each key and when it was last used. The timestamp updates on every authenticated ingest request. If it still reads “never” after deployment, Glyph has not received a request for that key. If a key leaks or you want to retire it, rotate it from Settings. Rotation invalidates the old value immediately; deploys still using it will get 401 responses, which the SDKs surface through the onError callback without retrying.

​
Where the key travels

The SDK sends the key as a bearer token on every ingest request:
Browser traffic necessarily exposes the key to anyone reading your page source. Use a dedicated key with the Browser purpose so abuse can be rotated without changing server deployments. Use Direct HTTP or Backfill for integrations that do not use an SDK. Keep server keys out of client bundles; a backend key has no reason to ship to browsers. Official SDKs also report their package name and version. Glyph stores this as diagnostic metadata, not as authentication: HTTP headers can be reproduced by any caller. Older SDK versions appear with an unknown client until they are upgraded. Direct HTTP requests remain unknown by design.