Key management
Creation, expiry, revocation, logs and security advice
Keys are managed under Account → Developer Center → API Keys. One account can hold several keys, each with its own scopes, rate limit and log entries.
Creating a key
| Item | Description |
|---|---|
| Name | For your own eyes, e.g. "Tmall plugin" or "warehouse script". Logs identify keys by name |
| Scopes | Fixed after creation. Need different scopes? Create another key, see scopes |
| Expiry | Never / 30 days / 90 days. An expired key returns 401 invalid_api_key |
The key is shown only once after creation. The list shows only its prefix from then on, for matching.
Revoking a key
Revocation is immediate: every later request gets 401 invalid_api_key, with a message saying the key was revoked.
Revoked keys are not deleted: the list shows them as revoked, and their name still appears in the logs. That way "which key made these requests last month" always has an answer.
Lost the key, suspect a leak, moved servers? Revoke and create a new one. There is no "reset".
Columns in the list
| Column | Description |
|---|---|
| Name / prefix | The prefix is the first few characters after sk_, for matching |
| Scopes | What you ticked at creation |
| Last used | The last time the key passed authentication |
| Status | Active / revoked / expired |
Early keys
Keys created before scopes existed have no scope record. They are treated as generate:write only, and keep the default limit of the time, 10 requests / 24 hours. To download images or get a higher limit, create a new key.
Logs
Developer Center → Logs records every request to /api/v1/** and keeps it for 30 days:
| Field | Description |
|---|---|
| Time | When the request arrived |
| Key | Which key was used (shown by name; requests from a website login show as "session") |
| Request | Method and path template, e.g. POST /api/v1/generate |
| Status | HTTP status code |
| Duration | Milliseconds |
request_id | Matches the X-Request-Id response header and the request_id in the error body |
Logs do not record request bodies, query parameters or response content. Downloads via /api/file/* are not in this table.
Security advice
- Keep keys server-side only. Never put one in a web page, mini program or client app; one packet capture and it is gone
- One key per use. One for the plugin, one for the script; a leak means revoking one key and nothing else is affected
- Tick only the scopes you need. A key that only pulls image packs should not have
generate:write, so it can't spend your credits - Rotate. Choose 90-day expiry, create a new key before it expires, switch, revoke the old one
- Unknown requests in the logs? Revoke first, investigate second
Photopurr Docs