Skip to main content

​
Check a proposed booking before saving

Call POST /api/v1/action-checks with your organization’s API key and await the response before committing the booking. Compare canonical identifiers from trusted booking/CRM data, not free-text names.
This example returns decision: "flag_mismatch", allowed: false, with a mismatch check. The three decisions are:
  • proceed: all supplied comparisons match, all supplied tools succeeded, and every declared required tool is reported as succeeded.
  • request_clarification: an input is missing, unusable, or a tool is pending/not called.
  • flag_mismatch: a comparison differs or a tool failed.
The response contains check keys and statuses, never the reference values. The API authenticates the agent inside the key’s organization. It performs no booking, ingestion, model call, or background job. It validates the supplied snapshot; it does not fetch CRM state or prevent concurrent changes. Recheck if the proposed booking changes, and keep your booking system’s transaction and idempotency protections. Do not commit on a timeout or non-200 response. Limits: 64 KiB request, 1–20 comparisons, up to 20 tool statuses. Paths address own object fields, at most six levels deep; arrays and objects are not scalar comparison values. Types must match; whitespace around strings is ignored. Missing/null/blank values and strings over 1,000 characters cannot pass. Declare up to 20 requiredTools separately from the reported tools. If a required key is omitted from tools, its check returns missing, with allowed: false and request_clarification (or flag_mismatch if another check fails). A matching doctor alone cannot approve that request. Required tools default to an empty list for existing clients; always send the list when you need execution prerequisites enforced. Tool keys must be unique and must not collide with comparison keys. Keys are case-sensitive after trimming. Build this list from trusted application policy, not from an LLM’s reported tool calls. The API cannot detect a prerequisite omitted from both lists. Require checks such as availability lookup before booking; do not require the booking operation itself to have succeeded before authorizing it. Report statuses from actual execution results. Rebuild the snapshot and recheck after any proposed doctor, appointment, or prerequisite state changes.

​
Map reference data into a monitor

In an AI analysis stage, expand Reference data. Add a field label and a dotted call-metadata path, such as booking.doctor_id or crm.patient_type. Mark inputs required when the stage cannot judge without them. Save the monitor normally; mappings travel with its pipeline version and historical analysis. Only mapped scalar fields enter the stage’s reference block. Each stage accepts 20 fields, up to 1,000 characters per scalar and 6,000 characters in total. Oversized or absent required inputs leave the monitor Not evaluated, with the missing field labels visible in its result trace. No model is called for that monitor. Optional missing fields are disclosed to the judge. These mappings are separate from the legacy Use call context option. Use stable requested/proposed doctor IDs for deterministic checks. An AI monitor can compare conversation evidence against CRM fields after the call, but is not the synchronous action check.

​
Explain transfers

Open Reports → Transfer analysis → Create transfer monitor. The editable preset includes appropriate/avoidable transfers, abandonment, reasons, new/existing patient type, task completion, and evidenced triggering questions.
  1. Select the agents and review the instructions against their permitted tasks.
  2. Add required reference mappings if policy or patient type needs CRM evidence.
  3. Test and save the monitor. Review expected volume and sampling before opting into historical analysis; opening a report never queues evaluations.
  4. Select the monitor and dates in Transfer analysis. The default is 14 days, bounded to 90 days, using UTC call dates.
Rates use known outcomes and show their numerators and denominators. Total calls and evaluated calls remain separate; missing, filtered, sampled-out and older monitor-version results do not become successful outcomes. Reason/patient/task breakdowns and example calls support manual review. Small samples are visible, not declared statistically significant. Questions require evidence of a link to the outcome; proximity alone does not prove causation.

​
Evaluate voice naturalness

Voice naturalness (preview) is disabled by default and is not live validated: synthetic audio requests returned AWS HTTP 500. Keep AUDIO_NATURALNESS_ENABLED=false on the app and worker until audio inference succeeds and multilingual examples have been reviewed; enable it on both only after that validation. The separate audio monitor is designed to assess the first 20 seconds of an isolated agent track for naturalness, prosody, and language suitability across audible languages. Correct words can still have poor delivery; an accent alone is not a failure. Degradation scores run from 0 (natural) to 100 (severe), with the monitor’s affected threshold defaulting to 50. This requires an isolated agent recording, worker audio decoding, and the opt-in AWS audio inference configuration. Mixed/noisy/insufficient audio, unsupported judgments and unavailable inference are Not evaluated, never a clean bill of health. A short clip cannot detect late-call defects or prove whether a caller is human. Validate scores with multilingual human reviewers before customer rollout; this is not a calibrated speech-quality benchmark.

​
Review costs without reducing compliance coverage

Open Reports → Cost report. Three ledgers remain separate: provider call charges, trace component estimates, and monitoring estimates. Provider charges may include the same costs as traces, so do not sum them. Unknown prices and unavailable telemetry are explicit. Monitoring costs use recorded usage and available prices, not invoice reconciliation. Company selection uses each call’s attribution. Historical usage without a conversation link stays unattributed and is excluded from company views. Ambiguous session references cannot attribute trace costs. Select only optional, non-compliance monitors in the savings estimator. The slider estimates an additional reduction of their currently recorded spend through filtering or sampling. Every monitor starts excluded, no setting is changed, and compliance checks must retain full coverage. Estimates exclude infrastructure and unrecorded usage. Programmatic reports use the same authenticated organization and company scope:
  • GET /api/v1/reports/costs?companyId=UUID&from=2026-08-24&to=2026-09-06
  • GET /api/v1/reports/transfers?metricId=UUID&companyId=UUID&from=2026-08-24&to=2026-09-06
Both require Reports entitlement. Company/date parameters are optional; transfer reports require a monitor ID. Results identify the effective date window. Saved written reports remain organization-wide snapshots and are hidden while a company is selected; return to All agents to read them.