AiDial Docs

#Integrations

The Integrations area covers partner-controlled connection points such as API keys and webhook/API contracts. Some integration contracts are exposed through direct API routes even when a portal UI panel is not yet visible for every action.

The workspace uses one client selector for the visible integration areas. API Keys, Webhooks, Single Sign-On, and SCIM are shown as separate tabs so each area keeps its own readiness state, empty state, and safe next actions without mixing unrelated controls on one long page. Create, test, enable, and save actions stay unavailable until the selected client scope and required fields are valid.

#Who Can Use It

RoleAccess
partner_adminManage assigned-client API keys and supported integration mutations where enabled.
partner_userView integration inventory in read-only mode where exposed.

Customer roles do not manage partner integrations.

#API Keys

The current Integrations page exposes selected-client API-key management for partner roles. See API Keys & Partner API for creation, one-time reveal, rotation, revocation, and direct API usage.

#Core Runtime Surfaces Versus Plugins

AiDial separates core runtime surfaces from plugins.

Core project surfaces include RAG, transfer, compliance, recording, transcript, webhook delivery, email, sms, identity_verification, caller_info, speech, testing, and provider domains such as providers.telephony, providers.stt, providers.tts, and providers.llm.

Plugins are external service integrations, such as booking, CRM, calendar, workflow, or phone-system integrations. Do not treat RAG as a plugin: RAG is the core knowledge-base/runtime surface used for approved content grounding and retrieval.

Some controls are visible in the portal, some are direct API/reference contracts, and some remain escalation-only. When a control is not visible for your organisation, do not infer that a hidden configuration-file edit path is partner self-service.

#Outbound Campaigns

Outbound campaign management is a dedicated partner operational surface at /outbound-campaigns. It covers campaign CRUD, CSV contact import, DNCR/registry wash evidence, launch validation, run/pause/resume/cancel controls, and reporting over the existing outbound runtime.

Use Outbound Campaigns for campaign workflows. Use the Integrations area for supporting connection points such as API keys, webhooks, phone numbers, knowledge bases, catalogs, SSO, and SCIM.

#Webhooks

The public API reference documents partner webhook routes for listing, creating, updating, deleting, rotating secrets, and sending tests. Where AiDial has enabled a portal UI for webhook management, use the selected-client Webhooks tab; otherwise treat the maintained direct API reference as the integration contract.

Treat webhook self-service as available only where AiDial has enabled the corresponding portal UI or direct API contract for your partner organisation. Webhook secrets must be handled like credentials and should never be pasted into support tickets or screenshots.

#Single Sign-On

The Integrations page includes tenant SSO governance for assigned clients where your role allows it.

Partner admins can maintain SAML/OIDC configuration and client-role mapping rules. Partner users can view SSO state in read-only mode. AiDial admins handle runtime-enforcement status and break-glass recovery authorisations.

Status wording separates three states:

  • saved provider configuration
  • policy enabled or disabled
  • runtime enforcement state: not enforced, pending activation, enforced, or failed

Role mappings assign only client roles: Client Staff, Client Admin, or Client Manager. Users without a matching active mapping receive no role assignment. Lower priority numbers are evaluated first.

Break-glass records authorise emergency recovery work only. They do not create portal sessions, impersonate a user, or bypass sign-in. Each grant, revoke, and use attempt requires a justification and is audited.

Do not paste IdP client secrets, SAML metadata XML, private certificates, screenshots of secret values, or raw audit logs into support tickets. The portal writes sensitive provider material once and later displays safe summaries only.

#SCIM Provisioning

The Integrations page includes tenant SCIM provisioning status for assigned clients where your role allows it.

Partner admins can enable or disable the provisioning intake for the selected client and data environment. Partner users can view the status in read-only mode. AiDial operations issues and rotates the provisioning API key separately; the portal never displays the key value.

Provisioning events are accepted only from trusted server-to-server delivery using an API key with the scim_provisioning scope. Browser requests and portal BFF routes do not send X-API-Key.

Role assignment is deny-by-default. A user upsert grants a tenant-scoped portal assignment only when the supplied group matches an active SSO group mapping. User deactivation and no-match upsert events remove only the scoped tenant assignment and active sessions; they do not affect the user's access to other tenants.

Duplicate event ids replay the stored safe outcome. Recent event summaries and observed groups are shown for operational awareness, without exposing secret material or raw provider payloads.

#Catalogs

Catalog routes provide controlled lookup data such as available voices or models. Catalog data is read-only and should be used to populate supported configuration choices rather than free-form provider settings.

#Knowledge Bases

Knowledge-base and source routes are partner integration contracts where enabled. They support the core rag runtime surface; they are not plugin configuration.

Use approved content workflows only. Do not upload customer secrets, private credentials, raw call transcripts, or unapproved personal information. Source access failures that involve private storage, crawling permissions, or customer-sensitive content should be escalated.

#Phone Numbers And Telephony

Phone-number lifecycle routes exist for list, import, update, assignment, unassignment, telephony registration, and deletion where enabled and authorised. These actions relate to providers.telephony and can affect live calling behaviour, so use the approved portal/API workflow and escalate anything involving production routing uncertainty.

#Messaging And Identity Integrations

email, sms, identity_verification, and caller_info can involve external provider accounts, customer contact data, or privacy-sensitive runtime context. Treat visible portal controls as bounded customer-safe settings. Provider account setup, delivery investigation, verification-provider errors, and caller-data uncertainty should be escalated rather than handled through support-ticket screenshots or raw payload sharing.

#Unsupported Or Escalated Work

Use Escalation Boundaries for:

  • plugin credentials or provider account setup
  • webhook delivery failures that require service logs
  • production phone-number routing changes outside the portal/API workflow
  • campaign launch blockers caused by runtime capacity, phone routing, provider setup, or unclear DNCR/compliance evidence
  • knowledge-base source failures involving private storage or crawling access
  • email, sms, identity verification, or caller-info provider issues involving customer data or credentials
  • catalog changes, model enablement, or provider availability questions
  • emergency disabling of an integration after a suspected secret exposure