> ## Documentation Index
> Fetch the complete documentation index at: https://www.glyphhq.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Write keys

> How write keys work: live and test environments, rotation, and exposure.

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

| Prefix        | Environment | Use for                                                                                                      |
| ------------- | ----------- | ------------------------------------------------------------------------------------------------------------ |
| `glyph_pk_`   | Live        | Real customer traffic in production.                                                                         |
| `glyph_test_` | Test        | Verifying an integration. Events land in an isolated test environment and never mix with live customer data. |

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](/docs/guides/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](/docs/reference/configuration#error-handling) without retrying.

## Where the key travels

The SDK sends the key as a bearer token on every ingest request:

```
Authorization: Bearer glyph_pk_...
```

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.