Overview

A programmatic way to build and manage your chatbot, for an AI agent or for your own code, with access you scope and revoke.

What it is

The Agent Gateway is a programmatic surface for building and managing your chatbot from outside the dashboard. It exposes the same things you work with there, your flows, knowledge base, storage tables, deployments, and conversations, as tools that can be called over a connection. Anything you would normally do by clicking through the dashboard, you can do through the gateway instead.

It is mainly a management surface. Most of its tools change things: building and publishing flows, configuring deployments, creating collections and sources, managing storage tables and rows. It also reads: searching knowledge, listing conversations, and reading transcripts.

Every call is authenticated with a token you create, limited to the scopes you grant, and confined to a workspace you belong to. Nothing done through the gateway can exceed what you could do in the dashboard yourself.

The Agent Gateway comes with the Pro and Business plans. A call that names a workspace on another plan is refused, and works again once the workspace moves to one of them.

Who calls it

The gateway serves two kinds of caller from one set of tools:

  • An AI agent, such as Claude Code, Claude Desktop, Cursor, or one you build, connecting over MCP. You point it at your workspace and it builds and manages your chatbot for you.
  • Your own code, a script or backend calling the REST API directly, for automating management tasks without an agent in the loop.

Both go through the same tools, the same scopes, and the same checks, so it does not matter which one you use.

What you can do

  • Flow: read a flow's graph and run its bot in test mode, as an anonymous visitor or as one your site signed in, see the settings a deployment actually runs with, and (with write access) build, edit, publish, and deploy flows and configure their deployments.
  • Knowledge: search the whole knowledge base or chosen collections, list collections and sources with their sync status and the pages each brought in, read documents, and (with write access) manage collections and sources.
  • Storage: read your storage tables and rows, and (with write access) create tables and add, update, or delete rows.
  • Leads: read your leads, including the ones your test runs captured when you ask for them, and (with write access) add leads, move them between statuses, add notes, or archive them.
  • Inbox: read the queue, closes, declines, escalations, missed service targets and support reports, and (with write access) work conversations: close or decline them, wait on the customer, set priority and VIP contacts, and finish wrap-up.
  • Workforce: manage teams, their inbox rules and service targets, support seats and time off.
  • Conversations: list conversations and read transcripts, and (with debug access) inspect a run's step trace. Transcripts are for workspace owners, managers and admins; a member sees each conversation's details without the messages.

The full, always-current list is on the Tool catalog page, which reads straight from the running gateway.

How access works

Access rests on three things:

  • A token you create on your profile. It carries the scopes you choose and, optionally, a list of workspaces it may reach.
  • A scope for every tool. A read tool needs a read scope, a write tool a write scope, and so on. A token that lacks a tool's scope cannot call it.
  • A workspace, named on every call. One token reaches every workspace you belong to, and each call says which one it runs in, so an agent can move between them freely. workspaces.list tells it which ones those are and what it may do in each.
Your role in a workspace still caps what a token can do there. In a workspace where you are a member, a token gets the read and run tools plus the workforce tools, which let you set your own time off (and your team's, if you supervise it). A member who is a builder also gets the tools that change, publish and deploy flows and change tables, and a knowledge manager the tools that change knowledge. Everything else stays with owners, managers and admins, even if you granted the token more.

Limits

  • 600 requests a minute per token, shared between MCP and REST. Beyond that the gateway answers with HTTP 429 until the minute is up. Wait a moment and retry.
  • 20 flow.run calls a minute per token, since every run can use your AI allowance. Each call counts, including each one in a batch. A call over the limit is refused on its own and the rest of the batch still runs.
  • At most 10 calls in one MCP batch. A larger batch is refused as a whole before any of its calls run. A batch counts as one request toward the rate limit.

Give each agent its own token so one busy agent cannot use up another's allowance.

Get started

  1. Create an access token from your profile and copy it.
  2. Connect an MCP client, or use the REST API.
  3. Call workspaces.list to see the workspaces the token can reach, then pass a workspace subdomain to each tool you use.
  4. Browse the Tool catalog to see what is available and what each tool returns.
Talk to sales
This form is running on UniversalChatbot.