Skip to main content
Status: Deprecated — The legacy paths still work, but stop working on 2026-07-11. Migrate to the /v1 paths before then.

​
Why we are doing this

Our public developer API is consolidating under a single /v1 prefix. Several customer-facing endpoints still lived under /project/:projectId/integration/* and /project/:projectId/webhooks/*, separate from the rest of the V1 API. Moving them under /v1 gives one consistent, documented, developer-key-authenticated surface. This is additive: the new /v1 paths are live now and the old paths keep working until the sunset date. Nothing breaks today.

​
Timeline

StageDateWhat happens
Announce2026-06-06New /v1 paths are live. Legacy paths keep working but return Deprecation and Sunset (HTTP-date) response headers.
Deprecation2026-06-06 → 2026-07-10Migration window. Legacy paths still work. We monitor legacy traffic.
Sunset2026-07-11Legacy paths stop accepting requests.
RemovedTBD (estimated 2026-07-18)Legacy code paths 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

All affected endpoints authenticate the same way as before (Developer Key dk_ or secret key via Authorization: Bearer). Only the path changes — the request and response bodies are unchanged.
Legacy pathNew /v1 path
POST /project/{id}/integration/api/chat/completionsPOST /v1/projects/{id}/chat/completions
POST /project/{id}/integration/api/sessionPOST /v1/projects/{id}/sessions
DELETE /project/{id}/integration/api/sessionDELETE /v1/projects/{id}/sessions
POST /project/{id}/integration/api/session/terminatePOST /v1/projects/{id}/sessions/terminate
GET /project/{id}/integration/api/session/{sessionId}GET /v1/projects/{id}/sessions/{sessionId}
POST /project/{id}/integration/api/session/searchPOST /v1/projects/{id}/sessions/search
GET /project/{id}/sessionGET /v1/projects/{id}/session-history
GET /project/{id}/session/statsGET /v1/projects/{id}/session-history/stats
GET /project/{id}/session/{sessionId}GET /v1/projects/{id}/session-history/{sessionId}
POST /project/{id}/webhooksPOST /v1/projects/{id}/webhooks
POST /project/{id}/webhooks/checkPOST /v1/projects/{id}/webhooks/check
DELETE /project/{id}/webhooks/{subscriptionId}DELETE /v1/projects/{id}/webhooks/{subscriptionId}
POST /project/{id}/integration/phone/call/outboundPOST /v1/calls/outbound
sessions vs session-history. These are two distinct families under /v1. /v1/projects/{id}/sessions/* covers the session lifecycle (create, end, terminate, search, and GET /{sessionId} for live runtime state). /v1/projects/{id}/session-history/* is read-only history (list, stats, and GET /{sessionId} for the full persisted transcript with events). Note that GET .../sessions/{sessionId} returns runtime state, while GET .../session-history/{sessionId} returns the recorded history — pick the one matching what you need.

​
How to migrate

Swap the path; keep your credential and request body as-is. Old (stops working on 2026-07-11): 
curl -X POST https://api.pathors.com/project/PROJECT_ID/integration/api/chat/completions \
  -H "Authorization: Bearer dk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "Hello!"}]}'
New: 
curl -X POST https://api.pathors.com/v1/projects/PROJECT_ID/chat/completions \
  -H "Authorization: Bearer dk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "Hello!"}]}'
The outbound call endpoint is the one exception where the shape differs slightly — /v1/calls/outbound takes the project context the V1 way. See Create Outbound Call.

​
Edge cases

I see a Deprecation / Sunset header before 2026-07-11. That is by design. The request still succeeds. The header signals that the path you used is on the legacy route. After 2026-07-11 the same call fails. My integration runs on a server I don’t fully control (n8n, Zapier, custom webhook). Update the URL in the integration’s settings, save/redeploy, and send one test request. The credential and body do not change — only the path. I use the secret key, not a developer key. The secret key continues to work on the new /v1 paths exactly as before.

​
Need help