> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base44.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations and agents

> Third-party connection and AI agent endpoints in the Compliance API

Both endpoints on this page require `compliance:inventory:read`.

## Integrations

`GET /{workspace_id}/integrations`

Returns one paginated list with a `kind` discriminator covering six connection types.

| Short name | `kind` | Description |
| - | - | - |
| `app` | `app_connection` | An app's connection to a third-party service. |
| `workspace` | `workspace_connector` | Customer-owned, bring-your-own-OAuth-app connectors. |
| `custom` | `custom_integration` | Customer-defined HTTP integrations. |
| `mcp` | `mcp_connection` | MCP server connections, owned either by an app or by a workspace member. |
| `member_mcp` | `member_mcp_connection` | MCP servers a member connected for their own builder sessions. |
| `member` | `user_workspace_connection` | Tools a workspace member connected with their own account for use in the builder. |

The "Kinds" column below uses the short names.

| Field | Type | Kinds | Notes |
| - | - | - | - |
| `id` | string | All | |
| `kind` | string | All | The discriminator, in full form. |
| `app_id` | string or null | `app`, `mcp` | Null on an app connection owned by the workspace and shared. |
| `integration_type` | string | `app`, `workspace`, `member` | For example `slack`, `gmail`, or `figma`. |
| `name` | string | `workspace`, `custom`, `mcp` | |
| `scopes[]` | array of strings | `app`, `workspace` | What the provider granted, not what was requested. Client secrets are never returned. |
| `connection_ownership` | string or null | `app` | `"app"` or `"workspace"`: whose OAuth credentials drive it. |
| `status` | string or null | `app` | |
| `connected_at` | timestamp or null | `app` | |
| `per_user_connection_count` | integer | `app` | Distinct end users with an active connection for this `app_id` and `integration_type`. |
| `slug` | string | `custom` | |
| `base_url` | string | `custom` | Reduced to host and path. |
| `endpoint_count` | integer | `custom` | |
| `url` | string | `mcp` | Reduced to host and path. |
| `enabled` | boolean | `mcp` | |
| `connected_member_count` | integer | `member` | Distinct members whose connection is active. |
| `member_count_by_status` | object | `member` | Distinct members per status. Values can overlap and need not sum to anything. |
| `connected_by_member_id` | string | `member_mcp` | The platform user ID of the member who connected the server. Join it to `user_id` in [Members](https://docs.base44.com/developers/references/compliance-api/get-started/workspace-and-members.md), not that endpoint's `id`, which is the membership. Requires `compliance:members:read`. Such a server appears in every workspace the member belongs to. |

People are counted, never listed. The `per_user_connection_count` field excludes abandoned attempts and revoked grants, so it's current access rather than history, and a user who reconnected counts once. Members' own tool connections are counts only, never identities.

A member-owned MCP server is the exception. It names its owner by platform ID, the same identity [Apps](https://docs.base44.com/developers/references/compliance-api/get-started/apps-and-domains.md) publishes for an app's owner. One member can hold an active connection and superseded records at the same time, which is why the per-status counts can overlap.

URLs are reduced to host and path because both are customer-typed, so a credential can land in a query string, and this API doesn't return key material.

```json theme={null}
{
  "data": [
    {
      "id": "int_1",
      "kind": "app_connection",
      "app_id": "app_42",
      "integration_type": "slack",
      "connection_ownership": "app",
      "scopes": ["chat:write"],
      "status": "active",
      "connected_at": "2026-01-11T09:00:00Z",
      "per_user_connection_count": 0
    },
    {
      "id": "int_3",
      "kind": "custom_integration",
      "slug": "billing-api",
      "name": "Billing API",
      "base_url": "https://api.billing.example.com",
      "endpoint_count": 4
    },
    {
      "id": "int_4",
      "kind": "user_workspace_connection",
      "integration_type": "figma",
      "connected_member_count": 3,
      "member_count_by_status": { "active": 3, "initiated": 5 }
    }
  ],
  "pagination": { "total": 3, "next_cursor": null, "has_more": false }
}
```

## Agents

`GET /{workspace_id}/agents`

Returns one row per AI agent: standalone agents, which are apps of type `user_agent`, and agents embedded inside apps. Standalone agents also appear in [Apps](https://docs.base44.com/developers/references/compliance-api/get-started/apps-and-domains.md), so agent identity and posture are there. This endpoint adds the agent's lifecycle and channel vocabulary, plus the model and anonymous-access flag for agents embedded in apps.

An agent belongs to the workspace it was created in, like any app, so a personal Super Agent sits in its owner's own workspace rather than this one.

| Field | Type | Notes |
| - | - | - |
| `id` | string | `{app_id}:{agent_name}`. |
| `app_id`, `agent_name` | string | Agent name. For a standalone Super Agent this is usually `your_agent`. |
| `standalone` | boolean | Standalone agent versus embedded in an app. |
| `lifecycle` | string | Lifecycle state. |
| `allow_anonymous_access` | boolean or null | The explicit anonymous-access flag. Null on a standalone agent, because the flag applies only to agents embedded in apps. |
| `model` | string or null | The configured LLM. Null on a standalone agent. |
| `channels[]` | array | `{ type, configured, active }`. The `type` is one of `whatsapp`, `telegram`, `line`, `imessage`, `slack`, `partner_clients`, or `phone`. No email channel exists. |

The `configured` and `active` fields are both null today, and the same seven channel types are listed for every agent. Neither is stored per agent and channel, and live state would need a call per provider on every scan. Read them as unknown. This endpoint doesn't tell you which channels an agent is actually reachable on.

A standalone Super Agent is listed whether or not agent configuration has been saved for it, because the app is the agent. Its `model` and `allow_anonymous_access` are null. The model is resolved per request from the model picker and the workspace's policy, so no stored value describes what it runs. Anonymous access is governed by the app's `visibility_effective` and `auth` fields in [Apps](https://docs.base44.com/developers/references/compliance-api/get-started/apps-and-domains.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.