Skip to main content

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.

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

StageDateWhat happens
Announce2026-04-12dk_ works on every route. sk_ / buzz_live_ keep working. Responses on legacy paths return Deprecation: true and Sunset headers.
Deprecation2026-04-12 → 2026-05-09Migration window. Legacy keys still work. We monitor legacy traffic.
Sunset2026-05-10Legacy keys stop being accepted. Requests using them will return 401 Unauthorized.
RemovedTBD (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.
  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): 
# 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: 
# 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