> ## Documentation Index > Fetch the complete documentation index at: https://docs.pathors.com/llms.txt > Use this file to discover all available pages before exploring further. # Legacy API Key Sunset > Migration guide for sk_ and buzz_live_ API keys to Developer Keys (dk_) **Status: Deprecated** — Legacy API keys still work, but will stop working on **2026-05-10**. Migrate to Developer Keys before then. ## Why we are removing this Legacy `sk_` (Project API Key) and `buzz_live_` (Integration API Key) were stored in plaintext, scoped only to a project, and could not be audited back to a user. **Developer Keys** (`dk_`) are stored as hashes, scoped to a user with project membership, and produce auditable access — the same key model now covers every public API path. Keeping two parallel auth schemes means every new endpoint has to reason about both. We are consolidating on `dk_` so the API surface is consistent and so we can ship per-key scopes (coming after this sunset). ## Timeline | Stage | Date | What happens | | ----------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Announce | 2026-04-12 | `dk_` works on every route. `sk_` / `buzz_live_` keep working. Responses on legacy paths return `Deprecation: true` and `Sunset` headers. | | Deprecation | 2026-04-12 → 2026-05-09 | Migration window. Legacy keys still work. We monitor legacy traffic. | | Sunset | **2026-05-10** | Legacy keys stop being accepted. Requests using them will return `401 Unauthorized`. | | Removed | TBD (estimated 2026-05-17) | Legacy code paths and `ApiKey` records are deleted. This page stays for reference. | The sunset date moves later if legacy traffic has not gone to zero. It does not move earlier. ## What is changing Three things are going away on 2026-05-10: 1. **`sk_...` Project API Keys** — created previously in *Project Settings → API Keys*. 2. **`buzz_live_...` Integration API Keys** — created previously in *Integrations → API*. 3. **`x-api-key` header** — the only header `sk_` accepted on the legacy `/knowledgebases/*` route. After 2026-05-10 the only accepted credential on every public endpoint is a Developer Key sent as `Authorization: Bearer dk_...`. ## How to migrate ### 1. Create a Developer Key 1. Sign in to [app.pathors.com](https://app.pathors.com). 2. Open **Developer Keys** from the account menu. 3. Click **Create Key**, name it after the integration that will use it, and **copy the plaintext value immediately** — it is only shown once. The key belongs to the user who created it. Make sure that user is a member of every project the integration needs to reach. ### 2. Replace the credential in your integration Old (any of these will stop working on 2026-05-10): ```bash theme={null} # sk_ via x-api-key header curl https://api.pathors.com/knowledgebases \ -H "x-api-key: sk_live_xxx" # sk_ via Authorization: Bearer curl https://api.pathors.com/knowledgebases \ -H "Authorization: Bearer sk_live_xxx" # buzz_live_ on completions endpoint curl https://api.pathors.com/project/PROJECT_ID/integration/api/chat/completions \ -H "Authorization: Bearer buzz_live_xxx" ``` New: ```bash theme={null} # Knowledgebase — note the new path curl https://api.pathors.com/v1/projects/PROJECT_ID/knowledgebases \ -H "Authorization: Bearer dk_xxx" # Completions — same path, just swap the key curl https://api.pathors.com/project/PROJECT_ID/integration/api/chat/completions \ -H "Authorization: Bearer dk_xxx" ``` Two changes worth calling out: * **Header**: always `Authorization: Bearer`. The `x-api-key` header is being removed entirely. * **Knowledgebase path**: `/knowledgebases/*` → `/v1/projects/{projectId}/knowledgebases/*`. The old path stops accepting requests on 2026-05-10. Previously the project was inferred from the `sk_` key; with `dk_` you specify the project in the URL. For non-knowledgebase routes (completions, sessions, projects, agent config, pathway, tools), the path is unchanged — only the key prefix changes. ### 3. Revoke your legacy keys Once your integration is on `dk_`, revoke the old keys so accidental fallback can not happen: 1. Open **Developer Keys**. 2. Scroll to **Legacy Integration Keys** (only visible while you still have legacy keys). 3. Click **Revoke** on each row, confirm in the dialog. Revoking is reversible only by creating a new key, not by un-revoking — so confirm the new `dk_` is working in production first. ## Edge cases **My integration runs on a server I don't fully control (n8n, Zapier, custom webhook).** Update the credential in the integration's settings UI, redeploy/save, and send one test request. Watch the response — a 401 after the swap means the new `dk_` does not have access to the project the integration is targeting (re-check membership). **I have several integrations sharing the same `sk_`.** Create one `dk_` per integration. Sharing a key across integrations is allowed but makes the audit log less useful and means revoking one integration revokes all of them. **I see a `Deprecation` / `Sunset` response header before 2026-05-10.** That is by design. The request still succeeds. The header is the signal that the route or the credential you used is on the legacy path. After 2026-05-10 the same call returns `401`. **The user who owns the `dk_` leaves the project / company.** The key stops working when the user loses project membership. For long-lived integrations, create the `dk_` under a service-account user or a stable owner, not the original engineer. **My `dk_` returns 401 even though it is correct.** Check, in order: the prefix is `dk_` (not `dk_live_`), the header is `Authorization: Bearer ...` (not `x-api-key`), the user owning the key is a member of the project the request targets, and the key was not revoked. Expired or revoked `dk_` requests do **not** silently fall back to legacy auth — they return 401. ## Need help * **Discord**: [#support](https://discord.gg/e8g86Hqae) * **Email**: [support@pathors.com](mailto:support@pathors.com)