Skip to main content
Audact
Explore a workflow

For integrators & partners

Keep the AI stack you built. Add a decision point before supported replies go out.

Use Audact's documented supported checks for an existing text agent, or explore Governed Voice AI for new customer conversations. See the exact API boundary, policy context and decision record before changing a client workflow.

Review one integrationExplore the API

Supported endpoints and tool permissions shown per operation; not all advertised tools are end-to-end validated.

Routes and status today

Your agent stays. The decision point sits at the supported boundary.

On a supported route, a proposed reply meets your configured rule before it goes out. Each route carries its status from Audact's product register, and a dashed line marks anything that is not a universal route.

Illustration of the boundary

In words: your existing agent reaches the supported integration boundary over one of four routes: the text check endpoint, the REST API, the MCP server or the TypeScript SDK, each with its status beside it. Other voice providers are not transparently in the path today and are scoped per integration. At the boundary your configured rule is applied and a decision record is written. The outcome is allow, modify or block. An allowed or modified reply goes out; on a block, your own stack supplies its fallback.

Your existing agent

The text agent or stack you already run for a client.

Integration methods

  • Text check endpointIn controlled testing

    OpenAI-compatible. Checks each reply of your own text agent.

  • REST APIWorking today

    The documented operations, with a tenant API key.

  • MCP serverWorking today

    Reachable with a tenant API key. Tools are confirmed one by one.

  • TypeScript SDKWorking today

    Client library for the documented operations.

Only replies your integration explicitly sends to the supported check are checked. Connecting a method does not enforce anything by itself.

Audact check

Your configured rule

Set with your client. For example: no delivery dates in a reply.

Supported integration boundary

The check returns one of three outcomes

Allow

The reply goes out as drafted.

Modify

A corrected reply goes out.

Reply out

What your customer receives from your stack.

Block

The reply is held back.

Your own fallback

Defined in your stack, not by Audact.

Decision record

Rule:
the version in force
Decision:
allow, modify or block
Input and output:
stored as hashes, not as words

Read it through the REST API or an export.

  • Solid blue: a route the product register shows as working or in testing
  • Dashed grey: not a universal route; scoped per integration

Other voice providers

Not transparently in the path today. Scoped per integration.

On Voice, if a check cannot finish

A check that misses its documented deadline releases the original draft unchanged. A FAIL_OPEN event is logged, and there is no normal receipt for that check.

A record is not a booking

The decision record shows what was checked and decided. It does not show that a booking, discount or payment happened in another system; only that system can confirm it.

In controlled testing

Starting fresh instead? Governed Voice AI runs new customer conversations on Audact's own voice stack.

See Governed Voice AI

An illustration of where the check sits, not a screenshot of a product console. The example rule is invented.

Two ways to start

Build with Audact, or bring the agent you already run.

Both end the same way: a supported response checked against your client's rules, and a record of the decision.

  • Path 1

    Build with Audact

    Build on Audact's platform, Voice included. Governed Voice AI handles the call; the REST API, the MCP server and the TypeScript SDK connect it to the tools you already use. Audact runs the voice stack, the rule checks and the records.

    Governed Voice AI
    In controlled testing
    REST API
    Working today

    Voice on the published Voice terms; production API access sits inside a paid agreement.

  • Path 2

    Bring your existing agent

    Already run a text agent? Keep it. Route its replies through Audact's OpenAI-compatible endpoint: each reply, not the prompt, is checked against your client's rules before it is returned, and each check is recorded.

    Check for your own text agents
    In controlled testing

    For text agents, through the supported endpoint; developer access by application. Voice runs on Audact's own voice stack, and actions in other systems are outside this check.

What stays yours

Your clients, your prices, your stack.

  • Your client relationship.

    The contract and the contact with your client stay with you. Who is party to which agreement is set per deployment.

  • Your prices.

    You set what you charge for your own services. Audact's part follows the published Voice terms or an agreed Enterprise Voice Pilot.

  • Your stack, where the route supports it.

    Text agents keep their model and setup through the supported endpoint; Voice runs on Audact's voice stack. We state per route what is supported, and nothing beyond it.

MCP server

Connect an assistant through the MCP server, with the limits in plain view.

The Model Context Protocol server on the API host exposes Audact operations as tools for an MCP client. Reaching the endpoint shows that it answers; each tool is confirmed on its own.

Access
A tenant API key, sent as a Bearer token. MCP clients that support only OAuth cannot connect.
Rights
Tools follow the key's role: Viewer is read-only, Developer can create and change, Owner can also delete and change settings. A tool call can do no more than the same key used directly against the REST API.
Money and irreversible actions
Tools that spend money, erase data irreversibly, control live calls or change security settings require explicit confirmation from the client (confirm: true). Other destructive tools, such as deleting an agent, rely on the key's role instead. Give an assistant the smallest role it needs.
Personal data
Two tools return decrypted personal data from calls into the assistant's context. Whether your assistant may receive it is a question for your data processing agreement; where it may not, use the REST API with your own access controls.
Per tool, not per endpoint
That the endpoint answers says nothing yet about a given tool. Which tools your route needs, and with which rights, we go through with you in scoping.

MCP server

MCP server: Is it built
Is it builtWorking today
MCP server: Can I get it
Can I get itEarly Customer Program
Why this status
Claim
Working today · Early Customer Program
Scope
The MCP endpoint /mcp/ on the API host and the tools it exposes. Not the Anthropic connector, which is a separate integration.
Ground
Measured on 21 October 2026: POST https://api.audact.ai/mcp/ without a key returns 401 with WWW-Authenticate: Bearer realm="audact" (the MCP server's own challenge).
What it does not establish
That every individual tool behind this endpoint works today. That is confirmed per tool, and the confirmation is open.
What you can get today
Access runs through onboarding inside an applicable paid agreement; the MCP server is not priced separately.
Last checked
21 October 2026
Where to check it
/mcp-server

Beyond replies

Actions in other systems come next, designed with partners.

Approving an action before it reaches another system, routing an exception to a person, reconciling what was promised with what the system of record shows: that is business-action Control. It could sit in the request path or run beside an agent you already have; that is part of the design work.

We explore it one action class at a time, as a design-partner conversation: no release date, no price, no quote.

Business-action ControlIn development

See the refund concept

Who it is for

Three kinds of partner, one control layer.

  • Agencies & answering services

    Voice agencies, answering services and telephony resellers that sell under their own brand.

    What you get
    Governed Voice AI for your clients, set up per client, with a decision record for each completed check.
    What Audact supplies
    The voice platform, the AI disclosure in the call, the rule checks and the records.

    See the agency offer

  • Integrators & implementation partners

    System integrators, IT service providers and AI implementation teams.

    What you get
    Keep the stack you chose for each client, and add a rule check on supported responses before they reach the customer.
    What Audact supplies
    The check for your own text agents, the REST API, the MCP server and the TypeScript SDK; developer access by application.

    Review one integration

  • Platforms: embed Audact

    Communication, customer-service and workflow platforms.

    What you get
    Rule checks on supported responses inside your own product, scoped per workflow.
    What Audact supplies
    The API, the checks and the records, scoped per workflow.

How it starts

From one integration to a go-live you both approve.

How an integration starts

The order we work in; there is no fixed timeline attached to it.

  1. 01

    Bring one workflow

    One client conversation, the rules that must hold, and what counts as done.

  2. 02

    Review the integration

    Which route fits, which operations and tool rights you need, and where the boundary sits.

  3. 03

    Developer access on approval

    Developer access by application, opened once the workflow is agreed.

  4. 04

    A paid deployment

    Production access sits inside a paid agreement: the published Voice terms or an Enterprise Voice Pilot.

  5. 05

    Go-live, approved together

    Each go-live is approved by you and by Audact.

Status

Status, part by part.

Each part carries its status from Audact's product register.

  • Governed Voice AI

    Voice agents with the rule check on supported replies before the caller hears them.

    Governed Voice AI: Is it built
    Is it builtIn controlled testing
    Governed Voice AI: Can I get it
    Can I get itEarly Customer Program
    Why this status
    Claim
    In controlled testing · Early Customer Program
    Scope
    The governed voice application for agencies: outbound and inbound calls with disclosure, policy enforcement and a receipt per governed interaction.
    Ground
    Calls run, but no paying deployment has gone through it.
    What it does not establish
    That a deployment is live with a paying customer, and that the delivery is production-hardened.
    What you can get today
    The Early Customer Program is open to a limited number of external agencies. Terms and figures are in the price book.
    National policy layer
    Germany: national policy layer active. Netherlands: in development. Belgium and Austria: planned.
    Intake
    Netherlands and Flanders (BE): intake open. Germany and Austria: intake is a conversation and not a start date.
    Last checked
    30 September 2026
    Where to check it
    /voice

  • Check for your own text agents

    An OpenAI-compatible endpoint that checks the replies of a text agent you already run.

    Check for your own text agents: Is it built
    Is it builtIn controlled testing
    Check for your own text agents: Can I get it
    Can I get itBy application
    Why this status
    Claim
    In controlled testing · By application
    Scope
    An OpenAI-compatible endpoint that checks the replies of a customer's own text agent against the customer's rules before they are returned, and records each check. It checks replies, not actions in other systems.
    Ground
    Passed all five QA conditions on staging on 20 October 2026: blocking, modifying, checking each reply in the test run, and recording each check.
    What it does not establish
    That it runs on production, and how it behaves under production load.
    What you can get today
    Developer access by application, inside an applicable paid agreement; not priced separately.
    Last checked
    24 October 2026
    Where to check it
    /docs

  • REST API

    The public REST API on the API host, reachable with a tenant API key.

    REST API: Is it built
    Is it builtWorking today
    REST API: Can I get it
    Can I get itEarly Customer Program
    Why this status
    Claim
    Working today · Early Customer Program
    Scope
    The public REST API on api.audact.ai/v1. The MCP server has its own register entry.
    Ground
    Measured on 21 October 2026: GET https://api.audact.ai/v1/health returns 200; protected /v1 routes return 401 with the standard error body. The public reference at /docs/api-reference lists every public operation.
    What it does not establish
    That every individual operation has been verified end to end in production.
    What you can get today
    Production access sits inside an applicable paid agreement. Endpoints are not priced separately.
    Last checked
    21 October 2026
    Where to check it
    /apis

  • MCP server

    The MCP endpoint on the API host; tools follow the key's role and are confirmed per tool.

    MCP server: Is it built
    Is it builtWorking today
    MCP server: Can I get it
    Can I get itEarly Customer Program
    Why this status
    Claim
    Working today · Early Customer Program
    Scope
    The MCP endpoint /mcp/ on the API host and the tools it exposes. Not the Anthropic connector, which is a separate integration.
    Ground
    Measured on 21 October 2026: POST https://api.audact.ai/mcp/ without a key returns 401 with WWW-Authenticate: Bearer realm="audact" (the MCP server's own challenge).
    What it does not establish
    That every individual tool behind this endpoint works today. That is confirmed per tool, and the confirmation is open.
    What you can get today
    Access runs through onboarding inside an applicable paid agreement; the MCP server is not priced separately.
    Last checked
    21 October 2026
    Where to check it
    /mcp-server

  • TypeScript SDK

    The TypeScript client library for the documented operations.

    TypeScript SDK: Is it built
    Is it builtWorking today
    TypeScript SDK: Can I get it
    Can I get itEarly Customer Program
    Why this status
    Claim
    Working today · Early Customer Program
    Scope
    The TypeScript client library documented at /docs/sdks/typescript. Not the Python and Go SDKs, which have their own entry.
    Ground
    The TypeScript SDK is published on npm as @audactcore/sdk 0.4.0 (measured 22 October 2026); parity tests cover 209 of 211 documented operations.
    What it does not establish
    That every documented operation has been exercised through the SDK against production.
    What you can get today
    Included in a paid agreement.
    Last checked
    21 October 2026
    Where to check it
    /docs/sdks/typescript

  • Connections to third-party systems

    CRM, automation and workspace connections, scoped inside a paid agreement.

    Integrations: Is it built
    Is it builtIn development
    Integrations: Can I get it
    Can I get itNot available
    Why this status
    Claim
    In development · Not available
    Scope
    The integrations with third-party systems: HubSpot, Pipedrive, Zapier and a customer's own Slack workspace. Not Cal.com: the voice product carries a native Cal.com integration, and it has the status of Voice. Reading availability or a deal stage, writing an outcome back, and posting an event from the voice product into a system that is not ours. Not the six endpoints of the API itself, which have their own entry, and not the notice Audact sends itself when a form on this site is submitted.
    Ground
    Measured on 30 September 2026 in the platform code (audact-monorepo): a Cal.com client is present (availability, booking, rescheduling, cancelling, OAuth) and its release acceptance is open; HubSpot, Pipedrive and Zapier have no client there. This website's own code only notifies Audact in Slack when a form is submitted.
    What it does not establish
    Which integration is built first, and when. No order among them has been decided and no date has been established.
    What you can get today
    Nothing to order. A connection is scoped inside an applicable paid agreement; integrations are not priced separately.
    Last checked
    30 September 2026
    Where to check it
    /integrations

  • Business-action Control

    Authority checks before an action reaches another system, with confirmation from that system.

    Control: Is it built
    Is it builtIn development
    Control: Can I get it
    Can I get itInternal only
    Why this status
    Claim
    In development · Internal only
    Scope
    The mandate and authority layer: ceilings, scope and the block in front of a governed action. The architecture is described; the runtime is being built.
    Ground
    There are no users.
    What it does not establish
    That any of it runs today, and that the figures in the interface come from a running system.
    What you can get today
    Not orderable. Design-partner conversations only, and only after the delivery gate is confirmed in writing.
    Last checked
    25 October 2026
    Where to check it
    /control

  • Governed Chat

    The same rule checks, for AI chat assistants.

    Governed Chat: Is it built
    Is it builtIn controlled testing
    Governed Chat: Can I get it
    Can I get itBy application
    Why this status
    Claim
    In controlled testing · By application
    Scope
    Governed Chat: the rule checks of Governed Voice AI for AI chat assistants. A proposed reply is checked against the customer's rules before it reaches the person in the chat, and the decision is recorded. It checks replies, not actions in other systems.
    Ground
    In controlled testing on the same control layer as Governed Voice AI. Not yet in customer use.
    What it does not establish
    A release date, and which chat channels come first.
    What you can get today
    Not orderable yet. Talk to us about one chat workflow; early access is decided per case.
    Last checked
    25 October 2026
    Where to check it
    /chat

  • Governed Email

    Designed to check what an AI-written email commits to before it is sent.

    Governed Email: Is it built
    Is it builtIn controlled testing
    Governed Email: Can I get it
    Can I get itBy application
    Why this status
    Claim
    In controlled testing · By application
    Scope
    Governed Email: checks what an AI-written business email commits to, such as a price, a date or a promise, against the customer's rules before it is sent, and records the decision. Whether the email was delivered, and whether the business outcome happened, only the systems that handle them can confirm.
    Ground
    A working email agent is in controlled testing on the same control layer as Governed Voice AI. Not yet in customer use.
    What it does not establish
    A release date, and which mail systems come first.
    What you can get today
    Not orderable yet. Talk to us about one email workflow with a clear limit; early access is decided per case.
    Last checked
    25 October 2026
    Where to check it
    /email

Questions

Questions partners ask.

Is there a partner programme?
No: no tiers, badges, certification or portal. You work with the people who build the product, one workflow at a time.
Do certifications carry over between us?
No. Each party's certifications cover its own services. Audact is not certified under ISO 27001 or SOC 2 today; the Trust page sets out the controls, the sub-processors and the data processing agreement.
Where is data hosted, and which models are used?
Hosting and models are set per component. Primary application hosting: Frankfurt. Some sub-processors in the path operate outside the EEA under standard contractual clauses; the Trust page lists each one with its country and transfer basis. Which model a deployment uses is agreed per component in scoping.
Can our clients keep their own model?
For text agents, yes: the check sits on an OpenAI-compatible endpoint, so a client's agent keeps its model and setup while its replies are checked against their rules. Voice runs on Audact's own voice stack, with the model agreed per deployment. Developer access is by application.
In controlled testing
Does a reachable MCP server mean every tool works?
No. A reachable endpoint shows that it answers. Each tool is confirmed on its own, and every tool follows the role of the key you use.
Working today
Which markets can we start in?
Intake by country, as Audact's register records it: Netherlands and Flanders (BE): intake open. Germany and Austria: intake is a conversation and not a start date.
Who is liable for what?
That depends on the setup and on the contracts between you, your client and Audact. A party that sells an AI agent under its own name may carry provider duties under the AI Act; we map the roles with you before go-live. General information, not legal advice.

Next step

Bring one integration.

Tell us which agent or stack you run, which conversation it handles for your client, and what it must never promise. We map the route and its boundary with you.

Review one integrationExplore the API