GET/api/crm/v1/settings/scheduling

CRM's scheduling configuration: who it offers for booking

Requires crm:settings:read. Configuring the module is a different privilege from operating it, which is why these scopes exist separately from the operational ones.

App
CRM
Contract
CRM API 9.12.1
Lifecycle
preview
Runtime
restricted
Operation ID
getSchedulingSettings
Canonical origin
Not declared; gateway routing required

Purpose and use cases

CRM's scheduling configuration: who it offers for booking

The owning App is Vision CRM. CRM owns its records, workflow rules, workspace membership, provenance, and record-level authorization.

Request

GET /api/crm/v1/settings/scheduling

This contract intentionally declares no direct server URL. Obtain the routed App origin before attempting the request.

Authentication and authorization

Send a Vision-issued bearer token for the exact App audience. The token must include the crm entitlement and satisfy the crm workspace required binding.

  • Required scope: crm:settings:read

Human roles are not declared in OpenAPI. Record-level and business permission checks remain the owning App's authority.

Headers

  • Authorization: Bearer <access-token> — required.
  • Accept: application/json — recommended where a JSON response is declared.

Undeclared tracing, idempotency, conditional-request, and version headers are not assumed on this page.

Path and query parameters

NameLocationTypeRulesDescription
qquerystringoptional; minimum length 2; maximum length 100Optional. Case-insensitive literal substring applied to each list: actors (name, reference, class, role, note), serviceLines (label, key), policies (meeting type, service line key/label, note). producer is unaffected.

Request body

This operation declares no request body.

Runnable examples

cURL
curl '${APP_BASE_URL}/api/crm/v1/settings/scheduling' \
  --request GET \
  --header 'authorization: Bearer ${ACCESS_TOKEN}' \
  --header 'accept: application/json'
JavaScript (server-side)
const response = await fetch('${APP_BASE_URL}/api/crm/v1/settings/scheduling', {
  method: 'GET',
  headers: {
    authorization: `Bearer ${ACCESS_TOKEN}`,
    accept: 'application/json',
  },
}

if (!response.ok) throw new Error(`Vision API ${response.status}`)
const result = await response.json()
Python 3 standard library
import json
import urllib.parse
import urllib.request

request = urllib.request.Request(
    '${APP_BASE_URL}/api/crm/v1/settings/scheduling',
    data=None,
    headers={
    "Accept": "application/json",
    "Authorization": "Bearer <ACCESS_TOKEN>"
},
    method='GET',
)
with urllib.request.urlopen(request, timeout=30) as response:
    result = json.load(response)

The current TypeScript reference client covers Platform token exchange and core reads. No native SDK helper is declared for this operation; use the HTTP contract directly and follow the SDK guidance.

Responses

StatusMeaningSchema
200Actors, policy ownership, and whether booking is possible at allobject

Success response schema

FieldTypeRulesDescription
schemaVersion"vision-crm-scheduling-settings.v4"requiredNot described in the contract.
actorsarrayrequired; maximum items 200Every active actor, offered or not -- listing only stored rows would hide everyone nobody has decided about yet.
producerobjectrequiredWhether booking can work at all. Nothing writes scheduling_slot outside tests, so offering an actor changes nothing while this is false -- and a screen of switches that implied otherwise would mislead the administrator using it.
producer.configuredSlotsintegerrequiredNot described in the contract.
producer.futureAvailableSlotsintegerrequiredNot described in the contract.
producer.availablebooleanrequiredNot described in the contract.
policiesarrayrequired; maximum items 40How long a meeting is, per meeting type, decided by an administrator. THERE IS NO DEFAULT and nothing is seeded: an empty list means nobody has decided, and booking cannot be offered until someone does. A seeded default would only move a hard-coded number one table further down. Today the only type is first_call; a longer escalated follow-up is another entry, not another release. Keyed by (meeting type, offering): one fallback row per meeting type plus one row per offering.
ownershipobjectrequiredWho owns each value. CRM owns what it is offering -- a first call of N minutes. Padding around an actor's other commitments is calendar's, and calendar does not hold it yet.
ownership.durationOwnedBycrm | calendarrequiredNot described in the contract.
ownership.conflictBufferOwnedBycrm | calendar | nobodyrequiredNot described in the contract.
serviceLinesarrayrequired; maximum items 60What this workspace sells. Empty until an administrator names them -- nothing is seeded, because a platform engagement, a website build and a consulting conversation are a workspace's decision and not CRM's. Disabled rather than deleted, since a line that stops being sold still has to explain the opportunities won under it.
200 illustrative response
{
  "schemaVersion": "vision-crm-scheduling-settings.v4",
  "actors": [
    {
      "publicReference": "<publicReference>",
      "displayName": "<displayName>",
      "identityClass": "human",
      "membershipRole": "<membershipRole>",
      "offered": true,
      "note": "<note>",
      "recordVersion": 1
    }
  ],
  "producer": {
    "configuredSlots": 1,
    "futureAvailableSlots": 1,
    "available": true
  },
  "policies": [
    {
      "reference": "<reference>",
      "meetingType": "<meetingType>",
      "durationMinutes": 5,
      "postMeetingBufferMinutes": 1,
      "note": "<note>",
      "recordVersion": 1,
      "serviceLine": "<serviceLine>"
    }
  ],
  "ownership": {
    "durationOwnedBy": "crm",
    "conflictBufferOwnedBy": "crm"
  },
  "serviceLines": [
    {
      "key": "<key>",
      "label": "<label>",
      "enabled": true,
      "sortOrder": 1,
      "recordVersion": 1
    }
  ]
}

Errors and troubleshooting

Error bodies and codes are shown only where the approved contract declares them. Use status, the declared error schema, and any correlation identifier returned by the App; do not infer that two Apps share one envelope.

    Collection behavior

    Pagination: not declared. Filtering/search: declared through the parameters above. Sorting: not declared.

    Cursor lifetime, cursor binding, stable ordering, maximum traversal, and unknown-filter behavior are not assumed unless stated by a parameter description or schema constraint above.

    Operational behavior

    • Rate limit: No operation-specific limit or 429 response is declared.
    • Retry: Retry only when the documented error model or response headers authorize it. Timeout and backoff values are not declared by this operation.
    • Idempotency: No idempotency header or replay window is declared.
    • Concurrency: No ETag, If-Match, or optimistic-version header is declared.

    Security and privacy

    • Keep client credentials and bearer tokens on trusted servers.
    • Send only to the exact approved HTTPS origin and audience.
    • Treat response data according to the owning App's classification and retention policy; the OpenAPI contract does not itself grant data access.
    • Do not log credentials, tokens, complete private payloads, or secrets.

    Edge cases and known documentation gaps

    • No direct server URL; gateway routing is unresolved here.
    • Business roles, timeout, retry budget, rate value, idempotency window, and concurrency behavior are absent unless explicitly stated above.

    Contract history and evidence