Authentication
Learn how to authenticate with the Wrytze API using API keys.
Every request to the Wrytze API must include a valid API key. This page explains how API keys work, how to use them, and how to keep them secure.
API key overview
API keys are the sole authentication method for the Wrytze REST API. Each key is created inside the Wrytze dashboard and is scoped to a single organization.
Key characteristics:
- Organization-scoped -- A key can only access blogs, categories, and tags belonging to the organization it was created in.
- Created in the dashboard -- Navigate to Settings > API to create, view, and revoke keys.
- Shown once -- The full key is displayed only at creation time. If you lose it, you must generate a new one.
- Hashed at rest -- Keys are stored as SHA-256 hashes in the database. Wrytze never stores or logs the raw key.
Using the X-API-Key header
Pass your API key in the X-API-Key HTTP header on every request:
curl -H "X-API-Key: wrz_abc123def456ghi789jkl012mnopqrs" \
"https://app.wrytze.com/api/v1/blogs?limit=10"If the key is missing or invalid, the API returns a 401 Unauthorized response:
{
"error": {
"message": "Invalid or missing API key. Provide a valid key in the X-API-Key header.",
"status": 401
}
}Key scoping
Each API key is scoped to a single organization. When a request is authenticated, the API automatically resolves the organization from the key and restricts all queries to that organization's data.
This means:
- You can only access published blogs belonging to your organization's websites.
- You can only list categories and tags from your organization's websites.
- You cannot access blogs, categories, or tags from other organizations, regardless of the IDs you provide.
If your organization manages multiple websites, a single API key can access content from all of them. Use the website_id query parameter on list endpoints to filter to a specific website when needed.
Key expiration
API keys can optionally have an expiration date set at creation time. When a key expires:
- All requests using that key return
401 Unauthorized. - The key cannot be reactivated. You must create a new one.
- Existing cached responses may continue to be served until the cache TTL expires, but no new authenticated requests will succeed.
To check whether a key has an expiration, visit Settings > API in the dashboard. Keys without an expiration date remain valid until explicitly revoked.
Key rotation
Rotating your API key means replacing an existing key with a new one. Follow this process to avoid downtime:
- Create a new key in Settings > API. Give it a descriptive name (e.g. "Production v2 -- Feb 2026").
- Update your application to use the new key. Deploy the change.
- Verify that requests are succeeding with the new key (check the dashboard analytics or your application logs).
- Revoke the old key in Settings > API. This takes effect immediately.
Revoking a key is irreversible. Make sure your application has fully switched to the new key before revoking the old one.
Rate limiting
Each API key is rate-limited to 100 requests per minute using a rolling window. The API returns rate-limit information in the response headers:
| Header | Description |
|---|---|
X-RateLimit-Remaining | Number of requests remaining in the current window. |
X-RateLimit-Reset | Unix timestamp (milliseconds) when the window resets. |
When the limit is exceeded, the API returns 429 Too Many Requests with a Retry-After header indicating how many seconds to wait:
{
"error": {
"message": "Rate limit exceeded",
"status": 429
}
}For details on handling rate limits gracefully, see the Rate Limits reference page.
Security best practices
Treat your API key like a password. A leaked key gives full read access to your organization's published content and consumes your rate limit.
Follow these practices to keep your API keys safe:
- Server-side only -- Never use API keys in client-side JavaScript, mobile apps, or anywhere the key can be inspected by end users. Make API calls from server components, API routes, or serverless functions.
- Environment variables -- Store keys in environment variables (
WRYTZE_API_KEY), not in code. Use your hosting provider's secrets management (e.g. Vercel environment variables, AWS Secrets Manager). - Never commit to version control -- Add
.envand similar files to.gitignore. If a key is accidentally committed, revoke it immediately and generate a new one. - Separate keys per environment -- Create distinct keys for development, staging, and production. This limits the blast radius if a key is compromised and makes it easy to revoke a single environment's access.
- Revoke compromised keys immediately -- If you suspect a key has been exposed, revoke it in Settings > API without delay and create a replacement.
- Set expiration dates -- For keys used in short-lived or experimental projects, set an expiration date so they automatically become inactive.
- Monitor usage -- Review API request analytics in the dashboard to detect unusual traffic patterns that might indicate unauthorized use.