API versioning and deprecation

On the hosted app (https://exhaleoncall.com), incoming webhooks use /webhooks/.... That is the URL Connections copies, and it is the path customer nginx proxies. Do not prefix those URLs with /v1. The customer host does not publish /v1/webhooks/....

The API process also mounts the same webhook routes under /v1. Browser apps call same-origin /api/.... Hosted nginx strips the /api prefix before the API, so /api/webhooks/... and /api/v1/... both reach the API. OAuth connect registers webhook subscriptions at {app}/api/webhooks/..., which arrives as /webhooks/....

Session and admin routes in these guides are written as /v1/auth/.... A public route catalog and language SDKs ship after launch. When they do, programmatic access stays under /v1.

Deprecation policy

When programmatic access is published:

1. Breaking changes to /v1 (removed fields, changed auth, removed routes) require a notice period of at least 90 days in the changelog before removal, unless a security issue forces a shorter window.
2. Additive changes (new optional fields, new routes under /v1) do not require a notice period.
3. When a future major version ships (/v2), /v1 remains available until its published sunset date.

Headers (future)

Exhale may add deprecation response headers (for example Deprecation / Sunset) when retiring a specific path. Until those ship, the changelog is the source of truth.

See also

• Errors & authentication
• Sources