Dokumentation

VAPI configuration

The VAPI agent editor supports configuration for the model, voice and transcriber, together with call plans such as voicemail detection, endpointing, analysis, artifacts and monitoring. Optional plans can be left unset.

Advanced plans use JSON controls. Smart endpointing supports a provider plan and the legacy smartEndpointingEnabled boolean or "livekit" selector. Analysis can include named structuredDataMultiPlan entries and outcomeIds. Server settings can include a credential ID, encrypted paths and a retry backoff plan.

Existing voice settings, including the 11labs provider, are preserved. Missing required settings use OpenAI gpt-4o, OpenAI alloy and Deepgram nova-2; explicitly supplied complete voice settings are not replaced.

Tool references belong in model.toolIds. Existing Google, Slack and GoHighLevel tool choices remain available; their internal names are translated into VAPI's API names when a tool is deployed.

Transcriber provider changes

AssemblyAI uses speechModel (for example, universal-3-5-pro); Deepgram uses model (for example, nova-3). Saving a VAPI config removes unsupported model fields for AssemblyAI, Azure, custom and native VAPI transcribers, even when the provider has not changed. Provider changes also remove known fields carried over unchanged from the previous provider. CLI configuration layers, direct deployment overrides and deployment previews apply the same rules, including entries in transcriber.fallbackPlan.transcribers.

The visual editor displays the selected provider's model field, including saved models newer than the local dropdown list. Saving an unchanged, valid AssemblyAI configuration preserves speechModel. New AssemblyAI model keys and non-string model values are rejected before persistence. An unchanged legacy model artifact already in storage is removed on save; imports also remove this artifact. AssemblyAI cleanup additionally removes the unsupported Deepgram fields smartFormat, mipOptOut, numerals, profanityFilter and redaction, including in fallback transcribers. Preview and deployment requests validate model types before creating deployment work. Current-agent backfill can be reviewed separately with the dry-run operator script documented in docs/el-426-validation.md. Historical deployment records and applied hashes are not rewritten.

Existing and imported transcribers retain forward compatibility with VAPI: unknown fields, values outside the generated schema snapshot and fallback metadata are not rejected by a new strict snapshot validator. VAPI still decides whether it accepts the outbound configuration. An auto-fallback plan does not need a manual transcribers array.

Missing or non-object primary transcribers use the existing Deepgram defaults during deployment; saving an agent does not add deployment defaults. Cleared optional provider fields are omitted from outbound JSON. Legacy UI fields backgroundDenoising and endUtteranceSilenceThreshold continue to be omitted, including for AssemblyAI.

Background speech denoising

Use the assistant-level Smart Denoising switch for both AssemblyAI and Deepgram. Switching transcribers preserves its setting. Deployments send the same shape for either transcriber:

{
  "backgroundSpeechDenoisingPlan": {
    "smartDenoisingPlan": { "enabled": true }
  }
}

Turning the switch off sends enabled: false. Leaving denoising unset does not enable it automatically. Existing fourierDenoisingPlan parameters are preserved; this change does not add advanced Fourier controls.

Legacy backgroundDenoisingEnabled and boolean backgroundSpeechDenoisingPlan values are converted on import, save and deployment. The new field takes precedence if both are present, and the deprecated key is removed. A data migration updates current Vapi agent configs; historical versions are normalized when used without rewriting their stored snapshots.

Saving an Elacity config does not by itself deploy it to Vapi. Use the existing deployment flow to update a remote assistant. For verification, retrieve the Vapi assistant after deployment and check backgroundSpeechDenoisingPlan.smartDenoisingPlan.enabled before and after changing transcribers, for both enabled and disabled states.

New provider settings in JSON

You can add provider settings in the JSON editor before Elacity has a dedicated control for them. Extra fields, including nested objects and arrays, remain in the saved JSON when you reload the editor or change another setting. Removing a field in the JSON editor removes it from the saved document. Unknown fields appear in both editor modes with Not yet validated for <provider> warnings; a warning does not prevent saving.

For example, AssemblyAI can be configured with:

{
  "transcriber": {
    "provider": "assembly-ai",
    "speechModel": "universal-3-6-pro",
    "languageCodes": ["en"]
  }
}

These particular fields are already included in Elacity's current schema catalog. Other new settings remain unvalidated locally until the catalog is updated. Changing the transcriber, model, or voice provider removes unchanged fields known to belong only to the previous provider. Unknown fields are retained for validation, because Elacity cannot infer their ownership safely.

Validation before deployment

Vapi agents can use inline prompt text in their JSON without linking a registry prompt. Deployment preserves that text and only resolves registry references when the agent actually declares them.

For full Vapi deployments containing unknown fields, Elacity first creates a temporary, unattached assistant, reads the fields back, and deletes that assistant before creating or updating the target. It does not attach a phone number or start a call. Vapi does not document a general assistant dry-run endpoint; this is a real temporary API resource, not a dry-run. It checks whether Vapi accepts and preserves the configuration, not whether a model or voice will work during a real call. Known-only deployments do not need this additional check.

If Vapi rejects a field, drops it, changes its value, or validation cannot complete, deployment stops with a readable error and the saved JSON is retained. If cleanup fails, the error includes the temporary assistant ID so an operator can delete it in Vapi before retrying. An interrupted request can also leave an unattached assistant named Elacity validation ...; inspect these before retrying.

Legacy compatibility rules remain outbound-only: known unsupported transcriber model leftovers and UI-only timing flags are not sent to Vapi. They are no longer erased from the saved JSON by an unrelated edit. Review and remove obsolete fields explicitly in the JSON editor. Reading an agent and deploying it do not migrate its stored source configuration.

The temporary-assistant validation described here is specific to Vapi. Other platforms use their existing deployment adapters and validation capabilities.

Warnings also cover extra fields inside message arrays and configuration blocks that the local schema does not yet describe. Their nested values remain intact, including empty strings, nulls, false and zero. Editing or deploying another field does not normalize these authored values.