An integration category is not a prebuilt connector
Calendars, CRMs, telephony, helpdesks and internal APIs represent different kinds of connection. Each needs a review of data direction, read/write permissions, limitations and completion signals. Displaying a familiar system’s logo would not prove that work has been done.
Bring a process description and documentation to OMO. We assess available access, what can be configured and what needs bespoke engineering. Readiness of a particular connector must be established separately.
How capability status is disclosed
“Verified existing” requires evidence of the working connection, a version or verification date, and explicit scope. “Configurable” means adapting a supported setting. “Custom engineering” means additional implementation. “Requires discovery” means feasibility has not yet been established.
This page does not publish verified prebuilt-connector evidence for the customer systems below. Their status is therefore “assessed during discovery,” not “already connected.” Existing telephone architecture alone cannot establish that your number can be ported or that a carrier supports the required transfer.
| Category | Data direction and action | Public status | Prerequisite |
|---|---|---|---|
| Calendar | Read availability; separately authorized creation or modification | Assessed during discovery | Documented API, time zone, conflict and duplicate controls |
| CRM | Read permitted fields or update a lead | Assessed during discovery | Customer scope, field mapping and write permission |
| Telephony | Receive a call and attempt an authorized transfer | Assessed during discovery | SIP/carrier conditions, number rights and an end-to-end route test |
| Helpdesk | Read status or create a service request | Assessed during discovery | Identity checks, a receiving owner and acknowledgment |
| Internal API | Agreed read, write or notification operations | Assessed during discovery | Documentation, sandbox, limits and an error contract |
Reading, writing and notifying are different actions
A read returns only permitted information. A write changes a record and may require caller confirmation or employee approval. A notification informs another system or person; sending it does not prove that the main operation completed.
For example, a booking may be confirmed while an SMS fails. That does not justify cancelling the appointment or creating another one. Track the two outcomes separately and tell the caller what actually happened.
- Expose only the tools and fields required for the task.
- Validate organization and customer scope server-side on every request.
- Keep credentials out of browser code, prompts and public forms.
Prevent duplicate writes when a response is lost
A missing response does not mean an action failed. Identify an operation with a unique idempotency key; a retry must refer to the same request. Check whether the record exists and reconcile its authoritative status before making another change.
Retries need bounded timing and attempt counts. If status cannot be recovered, pass the request to its owner as “outcome unknown.” Do not announce completion merely because an API accepted a request or a model intended it to succeed.
What should you provide for an assessment?
Start with the system name, desired action, a public documentation link and an example that contains no personal information. Real credentials are exchanged through an agreed secure channel, not in a public enquiry.
Approximate call volume, opening hours and peak-load patterns help establish capacity requirements. These inputs are used to plan service limits; unlimited concurrency is not implied.
- Which system is the source of truth?
- Which operations are read-only and which need writes?
- Who approves a change and owns an exception?
- Is there a sandbox with synthetic test records?
- How are confirmed, rejected and pending requests represented?
What is tested before a pilot?
A successful request is only one test case. Exercise revoked access, invalid fields, occupied resources, delayed responses and duplicate requests as well.
Agree the data contract
Define fields, permissions, error states and responsibility on each side.
Test in isolation
Use synthetic records for normal and exceptional paths without changing real customer data.
Compare the outcome
The spoken reply, tool request and business-system record must agree.
Pilot and observe
Measure latency, refusal, retries and recovery within agreed scope, with a stop and rollback path.
Common questions
Do we need an API?
A documented API, webhook or approved connector is often required. Alternatives need assessment; we do not promise screen scraping or access to every system.
Can we use our own number?
Number rights, SIP support, carrier conditions and routing need verification. An existing telephony integration does not establish compatibility with every number.
What happens if our system is unavailable?
Follow agreed bounded retries, status reconciliation and human handoff. Do not blindly create another record or report an unconfirmed success.
Where are integration credentials stored?
Secrets belong in secured server-side configuration with limited access. Public pages, browser code and contact forms are not credential-delivery channels.
Primary sources and scope
Checked on September 17, 2026. These sources explain technical mechanisms, not the availability of every capability in an OMO implementation. Proposed connections and examples require a separate assessment.
- Google AI — function calling
Model-proposed tool calls and application-side execution.
- LiveKit — call transfers
Transfer mechanisms require compatible, configured telephony.
- OWASP — prompt injection
Untrusted input, least privilege and controls for high-risk actions.