Skip to content

Get this Tempus account's settings (user)

How the account is configured, for a client deciding which screens to show. Read it once per session: the answer is the same for every user in the PBX.

Separate from the profile on purpose. The profile is assembled from one employee's active contract and returns 422 without one, so an account-wide answer could not be read by a client that has no employee in hand yet, or by one whose employee is between contracts.

Today it carries one field, approval_engine, which says whether requests are routed by approval chains or by the older validator rules. The two need different approval screens and cannot be told apart from the API version in the path.

Any authenticated user of the PBX may read it. Nothing here is privileged: it says how requests are routed, not who routes them.

HTTP: bearerAuth

User bearer token. Default authentication for customer-facing endpoints. Obtain a token by calling POST /login with your credentials, then send it on every subsequent request as Authorization: Bearer <token>. The token inherits the permissions and PBX scope of the authenticated user.

HTTP Authorization Scheme
bearer
Bearer format
Bearer <token>
pbx path · string · uuid *
UUID of the PBX tenant. Must be the tenant the token belongs to; anything else is refused with 403 rather than answered from another tenant.
accept header · string
example: application/json

Responses

OK. The account's settings.
Response schema
data*object
approval_engine*string
Which engine routes newly submitted requests, and therefore which approval screens to render. `approval_chains`: ordered steps, a quorum per step, supervisors outside the ladder who may settle a request at any point, and validators who can see a request they may not decide yet. `validator_rules`: one flat pool, no steps, no supervisors, anybody in the pool may decide at any time. Per account, not per API version: a v2 endpoint serves accounts on either engine, so this cannot be inferred from the path. Requests raised before an account switched keep the engine that raised them, so read each request's own `step` and `watcher`/`supervisor` fields to render it; `step: null` means no chain. An account only ever moves from `validator_rules` to `approval_chains`, never back.
enum: approval_chains validator_rules
example: approval_chains
Authorization Token Missing. This error is returned when the authorization token is missing.
Response schema
errorstring
Error message
example: Authorization Token is missing
Forbidden. The caller's token belongs to a different PBX than the one in the path.
Response schema
messagestring
example: You do not have access to this PBX.
Not found. No PBX with that id exists. Answered before the tenant check, so an unknown id and one belonging to somebody else are not distinguishable from outside.
Response schema
messagestring
example: No query results for model [App\Models\Pbx].
get https://cockpit.voxbi.com/api/v1/v2/{pbx}/settings
Base URL
Request sample
curl -X GET 'https://cockpit.voxbi.com/api/v1/v2/{pbx}/settings' \
  -H 'Authorization: Bearer YOUR_TOKEN'
const response = await fetch('https://cockpit.voxbi.com/api/v1/v2/{pbx}/settings', {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${YOUR_TOKEN}`,
  },
});

const data = await response.json();
console.log(data);
import requests

response = requests.get('https://cockpit.voxbi.com/api/v1/v2/{pbx}/settings',
    headers={'Authorization': f'Bearer {YOUR_TOKEN}'}
)
response.raise_for_status()
data = response.json()
print(data)
<?php
$context = stream_context_create([
    'http' => [
        'method'  => 'GET',
        'header'  => "Content-Type: application/json\r\nAuthorization: Bearer YOUR_TOKEN",
    ],
]);

$response = file_get_contents('https://cockpit.voxbi.com/api/v1/v2/{pbx}/settings', false, $context);
$data = json_decode($response, true);
print_r($data);
{ … }
"data": { … }
"approval_engine": "approval_chains"
}
}
{ … }
"error": "Authorization Token is missing"
}
Cache-Control string
example: private, must-revalidate
Connection string
example: keep-alive
Content-Type string
example: application/json
Vary string
example: Origin
X-RateLimit-Limit integer
Max requests allowed in the current rate-limit window.
example: 60
X-RateLimit-Remaining integer
Requests remaining in the current rate-limit window.
example: 57
No example for this status.
No example for this status.