The v1 surface is completely covered by CAPI. The frictions are: two GET → POST verb changes, a flipped default on autoAnswer, the loss of Basic Auth, and the lack of a single "current user identity" endpoint.
Pre-flight
Base URL changes
- https://api.telavox.se + https://admin.telavox.com/api/capi
Authentication is Bearer JWT only
v1 accepted either Basic Auth or a Bearer JWT. CAPI accepts only Bearer JWTs. Switching is not just a path change — it materially improves the security posture of your integration:
- A JWT is per-integration, not per-user — revoking it removes the integration, no password reset required.
- JWTs can be rotated and short-lived; Basic Auth is the user's real password, sent on every request.
- If a JWT leaks, you revoke it from the Flow web app. If a Basic password leaks, you have to change a human password (often blocking that human's access to other tools).
- JWTs carry scopes/claims for fine-grained access. Basic Auth is all-or-nothing.
- Sending the password on every request increases the surface area where it can be logged, captured, or seen.
Endpoint mapping
| v1 | CAPI | Notes |
|---|---|---|
GET /extensions/ | GET /v1/extensions/users | Lists users only — PBX resources (queues, IVRs, faxes, …) live under /v1/extensions/pbx. |
GET /extensions/{ext} | GET /v1/extensions/users/{user} or GET /v1/extensions/pbx/{extension} | Split by resource type. Use users/{user} for a person, pbx/{extension} for a queue / IVR / shared-voicemail. |
GET /extensions/me | (no direct equivalent) | CAPI exposes per-user actions under /v1/extensions/users/me/… but no single object that names your own extension. See gap #1 below. |
GET /calls | GET /v1/extensions/users/me/calls/history | fromDate / toDate behave the same; new optional callType filter. withRecordings is gone — call /v1/extensions/users/me/calls/recordings separately if needed. |
GET /dial/{number}?autoanswer=… | POST /v1/extensions/users/me/dial body { phoneNumber, autoAnswer } | Verb change: GET → POST. Number moves URL → body. autoAnswer default flipped — see gap #3. |
GET /sms/{number}?message=… | POST /v1/extensions/users/me/sms body { phoneNumber, message } | Verb change: GET → POST. Both fields move URL → body. |
POST /hangup | POST /v1/extensions/users/me/hangup | Same verb, deeper path. No body, no params. |
GET /recordings/{recordingId} | GET /v1/extensions/users/calls/recordings/{recording} | Same shape, deeper path. Still returns the audio bytestream. |
Feature gaps to plan around
1. No single "who am I" endpoint.
v1's GET /extensions/me returned the caller's extension as one object with extension, name, email, profile, ongoing calls, and keyWords. CAPI exposes per-user actions under /v1/extensions/users/me/… but does not surface a single endpoint that names your own extension. If your integration relies on that, you'll need to discover the user's extension from the JWT issuance flow (it is bound to the token) or from another source before calling CAPI.
2. The extensions payload is now multi-call.
v1's response interleaved live state (current profile, ongoing calls array) with static info. CAPI normalises this — to recreate v1's shape you fetch the user, then /profiles/active, then /calls/history. Faster for clients that only need a subset; more requests for clients that need everything.
3. The autoAnswer default flipped.
v1 defaulted to true (the call auto-answered on the originating endpoint). CAPI defaults to false (the originator has to accept the incoming leg first). Clients that depended on v1's default behaviour must set autoAnswer: true explicitly. Naming also changed: autoanswer → autoAnswer.
4. No Basic Auth on CAPI.
See the Pre-flight section above — the move to Bearer-only is a feature, not a friction, but it is a required change if your integration still sends Basic Authorization. Create a JWT from Settings → My Account in Flow.
5. dial and sms are POSTs now.
Side-effect operations should always have been POSTs. Browser / CLI snippets that fired these as GETs need to send JSON bodies — they cannot be done with a single curl URL anymore. The bodies are small: {phoneNumber, autoAnswer} and {phoneNumber, message} respectively.
Side-by-side
A quick before/after for the two operations that change shape the most.
v1 — dial
curl 'https://api.telavox.se/dial/0701234567?autoanswer=false' \
-H 'Authorization: Bearer <jwt>'CAPI — dial
curl -X POST 'https://admin.telavox.com/api/capi/v1/extensions/users/me/dial' \
-H 'Authorization: Bearer <jwt>' \
-H 'Content-Type: application/json' \
-d '{ "phoneNumber": "0701234567", "autoAnswer": true }'v1 — send SMS
curl 'https://api.telavox.se/sms/0701234567?message=hello' \
-H 'Authorization: Bearer <jwt>'CAPI — send SMS
curl -X POST 'https://admin.telavox.com/api/capi/v1/extensions/users/me/sms' \
-H 'Authorization: Bearer <jwt>' \
-H 'Content-Type: application/json' \
-d '{ "phoneNumber": "0701234567", "message": "hello" }'What else CAPI adds
CAPI exposes a much larger surface than v1: full PBX administration (queues, IVRs, shared voicemail, faxes, license / permission management), phone-number / terminal / product / template CRUD, contacts, groups, delivery and invoice places. None of this existed in v1; you do not have to consume any of it to migrate, but it is available if you want it.